github takım iş akışı - çatal ya da değil?

Şu anda yıkımı kullanan küçük bir web geliştiricileri ekibiyiz ancak yakında github'a geçiyoruz.

Farklı tipte github iş akışlarına bakıyorum ve her geliştirici için github'daki tüm çatal konseptinin bizim için iyi bir fikir olup olmadığından emin değiliz.

Çatal kullanırsak, her geliştiricinin kendi özel uzak ve yerel depolarına sahip olacağını biliyorum. Değişiklikleri zorlaştırıp zorlaştıracağından endişeliyim. Ayrıca, benim en büyük kaygım, her geliştiriciyi 2 uzaktan kumandaya zorlayacağıdır: kökeni (uzak çatal) ve yukarı havza (ana depodaki değişiklikleri "senkronize etmek" için kullanılan). Bir şeyleri yapmanın kolay bir yol olup olmadığından emin değilim.

Bu, burada açıklanan iş akışına benzer: https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow

Çatal kullanmazsak, üzerinde çalıştığımız her görev için bir şube yaratan merkezi bir repo kullanarak muhtemelen para cezası alabiliriz ve bunları aynı depodaki geliştirme kolunda birleştirebiliriz. Bu, şubelerin birleşmesini sınırlayamayacağımız ve merkezi depoda birçok şubeye sahip olmak için biraz dağınık olacağımız anlamına gelir.

Her iki iş akışını da deneyen ekiplerden bir öneriniz var mı?

Sanırım çatallanma korkunuz, SVN'nin yıldızların birleşmesinden daha azından kaynaklanıyor - çünkü soruna neden olan çatal değil - birleşme.

Dalın - gerçekten harika bulacaksınız! Aşırı çatallamanıza gerek yoktur (her dosyadaki her değişiklik için çatal kullanmayın), ancak özellikler için çatal oluşturabilir ve tekrar birleşebilirsiniz.

GitHub'ı, kaynak kontrolündeki temel kavramların çoğunda iyileştirmeye değer birkaç versiyon olarak düşünün.

"Kararlı" bir dal ve "aktif gelişim" çatalı kavramı, çatallaşmaya tereddüt etmekte tereddüt ediyorsanız, bu sorunların çoğunu da kapsar. : P

İkisini de denedik, svn'de evde olan geliştiricilerle. Zaten birlikte çalışan ve birbirlerine bağlı haklarla güven duyan bir grup geliştiriciyseniz, muhtemelen tek bir merkezi depoyu gitmeye devam etmeyi ve sizi o repoyu destekleyen ortak çalışanlar olarak eklemeyi daha kolay bulacaksınız.

Yine de bazen özel çatal kullanıyoruz, ancak bu tipik olarak egzotik değişiklikler veya geri kalanının genellikle ilgilenmediği, ancak herhangi bir şekilde uzaktan saklamak istediğimiz 1 kişilik testler içindir.

Tek bir merkezi depo ile başlar ve bir süreliğine git ile çalışırdım. Belki özel çatal sana yetişir, belki değil. Her ikisi de iyi.

Git, bir çatal gerçekten başka bir dalıdır. Her geliştirici için çatal iş akışı ile, her geliştiricinin, geliştirme değişikliklerini izlemek için ortak (uzak) bir şubesi olmasını etkili bir şekilde zorunlu kılıyorsunuz. Bu, geliştiriciler arasında doğrudan (eşler arası) işbirliği yapabilmek için yararlıdır. Her durumda, geliştiricinin değişikliklerini merkezi repoda birleştirmek zorunda kalacaksınız, bu nedenle bunun fazladan bir ek yükü olduğunu sanmıyorum.

2-3 geliştiriciden oluşan küçük bir ekip için, düzeltmeleri ve özellikleri yönetmek için depoda dallanma kullanmak sorun değil. Mesele, bundan daha fazla geliştiriciye sahip olduğunuz ve geliştirilmekte olan daha fazla özellik ve düzeltmelerdir.

Bu durumda, Github'daki ana deponuz yüzlerce şubeye sahip olacak; bazıları yaşlı, unutulmuş ve unutulmamış olacak.

Ayrıca, birisinin depodaki ortak bir şubeye zorladığı bir işbirliği ile ilgili sorunlarınız olacaktır. Bu, hiç kimsenin o dalda düzgün bir şekilde işbirliği yapamayacağı anlamına gelir; çünkü zorla bir tarihin yeniden yazılmasıdır.

Bir repo oluşturmak, hangi şubelerin çalıştığını ve hangilerinin iyi olduğunu izlemeyi kolaylaştırır. Ana repoyu temiz tutar.

Ancak, test altyapınız ana reponun kullanılmasına bağlı olabilir, bu nedenle dalı yukarı doğru itmediğiniz sürece çatallı reponuzdaki değişiklikleri test etmek daha zor olabilir. Dallanma ve çatallamanın ne zaman en iyisi olduğunu anlamak zor olabilir ama genel olarak, takımın 4 kişiden fazlası olduğunda ve çok sayıda düzeltme ve özellik bulunduğunda, çatallama en iyi seçenektir.