Bir projede 2 kişiyle iş akışı nedir

Sana kendi projesi üzerinde çalışan bir acemi programcı olarak geldim (ki bu iyi ilerliyor). Kurucu ortak programlamayı da öğreniyor ve muhtemelen bazı şeyleri düzeltmeye ve bazı şeyleri gerçekleştirmeye başlayabileceği bir noktaya ulaştı.

Çok iyi bir soru sordu, bu da "bu nasıl olacak" idi. Başka biriyle hiç programlamamış olduğum için sadece kuramsallaşabileceğim bir şey. Bana en iyi iş akışı hakkında tavsiyede bulunabilir misiniz? Git kullanıyoruz.

Sistemin belirli kısımlarına sahip miyiz? Kodu kontrol ediyor musunuz? Kod incelemesi?

> 1 dev ile nasıl çalışıyorsunuz?

Git'i kullanan bir ekipte çalışıyorum, burada 40+ geliştirici herhangi bir zamanda birden fazla kod deposunda (100+) çalışıyor. Ayrıca birkaç geliştirici ile başladık, birkaç yıl içinde ekip boyutunu büyüttük. Başlangıçta az sayıda insanla sadece en az git gitmeyi bilerek kaçabilirsiniz. Zamanla git fu'nuzu geliştirerek güçlü özellikleri keşfedeceksiniz.

1. Kodunuzu barındıracak bir yere ihtiyacınız olacak. Kullanmayı düşünün GitHub veya gitorious . Her ikisini de kullanmak ücretsizdir, ancak havuzlarınız herkese açık olacak ve başkaları tarafından görülebilir olacaktır. Özel depolar istiyorsanız, bunları github'da ücretsiz olarak barındırabilir veya kendi zarif sunucunuzu kurabilir ve barındırabilirsiniz .
2. Başlangıçta, çatal çekme, çekme istekleri içeren gelişmiş iş akışları hakkında endişelenmemek daha iyidir. Git'i merkezi bir şekilde kullanarak başlayabilirsiniz (ürperti!). Barındırılan kopyanızı kaynak kodunuzun yetkili kopyası olarak kabul edin. Bu depoya bakalım upstream.
3. Biriniz tüm kodu yerel bir git deposuna kaydeder ve bu upstreamdepoya iletirsiniz.
4. Diğer ekip üyesi bu havuzu klonlayabilir.
5. Öğrenmek gereken minimum komut kümesi vardır clone, pull, push, add, commit, log, status, diff, branch, stash, apply, reset, format-patch, branch. Gittutorial'dan onlar hakkında daha fazla bilgi edinin .
6. İkiniz de artık kodun herhangi bir parçası üzerinde çalışabilirsiniz. İkiniz de aynı dosyayı düzenlediğinizde ne olacağından endişe etmeyin. Git birleşmeleri ve çatışmaları çözmede gerçekten çok iyi.
7. Küçük atomik taahhütler yapın ve iyi günlük mesajları yazın . İşlem günlükleri için şimdiki zamanı kullanın. Diğer kişinin çalışmasını etkilemediği için yerel kopyanıza istediğiniz sayıda taahhütte bulunabilirsiniz.
8. Kodunuzun başkalarıyla paylaşılmaya hazır olduğunu düşündüğünüzde, upstreamdepoya yayınlayın . İyi bir uygulama, itmeden önce her zaman çekmektir . Bu şekilde deponuzu diğer değişikliklerle senkronize halde tutarsınız.
9. Adımları tekrarlayın 7ve 8.

Bu iş akışından memnun kaldığınızda, topikal dallar, çatal, çekme istekleri, birleştirme, etkileşimli olarak yeniden basma taahhütleri vb.

Gerçekten kod incelemeleri istiyorsanız, sadece git ve e-posta ile yapılabilir. Takımınızın büyüklüğü 10'dan fazla büyüdüğünde, bu bir tür çevrimiçi araçla ideal olarak daha iyi yapılır. Yani pratikte bunu yapmanın birçok yolu var ve bu sadece basit bir yol:

1. İncelenecek bir dizi taahhüt oluşturun git format-patch. Bu bir dizi yama dosyası oluşturur. Bu yamaları incelemeye e-postayla gönderin.
2. Hakem yamaları ile uygulayabilir git apply. Bu, yamayı uygular, ancak bir taahhüt oluşturmaz.
3. Kodu ve e-postayı önerilerle birlikte inceleyin.
4. Tatmin edilene kadar 1-2-3'ü tekrarlayın.
5. İnceleyen, yamaların itilebileceğini onaylar upstream.

Bunun için github ve tüm işlevlerini kullanıyorum. http://www.github.com/ adresinden kontrol edin. Böylece partnerinizle çalışmak için şubeleri, çatalları, sorunları, istekleri kullanabilirsiniz.

Yapacağım ilk şey, değişikliklerin birleştirilebilmesi ve iki projeniz arasında senkronize tutulabilmesi için merkezi bir kod deposuna bakmaktır. SVN, geçmişte kullandığım iyi bir kolay ve oldukça olgun SVN olması yeterince uzun sürdü .

Bundan sonra ikiniz arasında rol oynayacağım ya ikiniz de rol oynayacaksınız yani

1. Kodun işlevselliğini tandomda mı yazacaksınız, yoksa bir kişi hata düzeltmeleri yapacak, diğeri ise özelliklerle devam edecek mi?
2. Brace konumu, özel üye değişken adlandırma, değişken ve yöntem adlandırma kuralı (CamelCase vb.) Gibi bir dizi temel kodlama standardı oluşturmak istiyor musunuz?
3. Ne sıklıkta check-in yapmanız gerekiyor. Her ikisinin de diğerinin özellikle erken ne yaptığını gördüğünüzden emin olmak için günde en az bir kez öneriyorum. Her zaman bir check-in önce kodu oluşturmak emin olun.
4. O patron, ama programlama lideri olacak mısın?

İyi şanslar!