Github Organizasyon Depoları, Sorunları, Birden Çok Geliştiricisi ve Forking - En İyi İş Akışı Uygulamaları

Tuhaf bir başlık, evet, ama sanırım örtbas edeceğim bir yerim var.

Github'da özel depoları olan bir organizasyon hesabımız var. Github'un yerel sorunları / çekme istekleri özelliklerini kullanmak istiyoruz (çekme istekleri, kod incelemeleri ve özellik tartışmaları kadarıyla tam olarak istediğimiz şeydir). Biz aracı bulundu hub tarafından defunkt çekme isteğine varolan sorunu dönüştürmek ve otomatik onunla geçerli dalı ilişkilendirmek mümkün olmanın bir serin küçük özelliği vardır.

Organizasyondaki her geliştiricinin, kendi özellik çalışması / hata düzeltmeleri / vb. Yapmak için kuruluşun deposunu çatallaştırmasının en iyi uygulama olup olmadığını merak ediyorum. Bu oldukça sağlam bir iş akışı gibi görünüyor (temelde github'daki her açık kaynak projesinin yaptığı gibi), ancak sorunları izleyebileceğimizden ve kuruluşun deposu olan ONE kaynağından istekleri çekebileceğimizden emin olmak istiyoruz.

Birkaç sorum var:

1. Bu durumda geliştirici başına çatal yaklaşımı uygun mu? Biraz abartılı olabilir gibi görünüyor. Doğrudan push erişimine sahip olmayan ve tüm kodlarını gözden geçirmeye ihtiyaç duyan geliştiricileri tanıtmadıkça, her geliştirici için bir çatala ihtiyacımız olduğundan emin değilim. Bu durumda, yalnızca bu geliştiriciler için böyle bir politika oluşturmak istiyoruz. Peki hangisi daha iyi? Tüm geliştiriciler tek bir depoda mı yoksa herkes için çatal mı?
2. Hub aracıyla, özellikle çekme isteği özelliğiyle ilgili deneyimi olan var mı? Geliştirici başına çatal (veya daha az ayrıcalıklı geliştiriciler için bile) yaparsak, hub'ın çekme isteği özelliği, akış yukarı ana depodan (kuruluşun deposu?) Çekme isteklerinde çalışır mı yoksa farklı davranışı olur mu?

EDIT Sorun
, çatal ve çekme istekleri ile bazı testler yaptım ve buldum. Kuruluşunuzun deposunda bir sorun oluşturursanız, deposu kuruluşunuzdan kendi github hesabınıza çatallayın, bazı değişiklikler yapın, çatalınızın ana dalıyla birleştirin. Çalıştırmaya çalıştığınızda hub -i <issue #>bir hata alıyorsunuz User is not authorized to modify the issue. Görünüşe göre iş akışı çalışmaz.

Bu durumda geliştirici başına çatal yaklaşımı uygun mu? Biraz abartılı olabilir gibi görünüyor. Doğrudan push erişimine sahip olmayan ve tüm kodlarını gözden geçirmeye ihtiyaç duyan geliştiricileri tanıtmadıkça, her geliştirici için bir çatala ihtiyacımız olduğundan emin değilim. Bu durumda, yalnızca bu geliştiriciler için böyle bir politika oluşturmak istiyoruz. Peki hangisi daha iyi? Tüm geliştiriciler tek bir depoda mı yoksa herkes için çatal mı?

Ekibinizin ölçeğine bağlı, sanırım. Eskiden tek bir repoya sahip olduğumuz küçük bir ekipte çalışıyordum ve bu repoda özelliklerin kendi dalları vardı. Bu bizim için iyi çalıştı.

Ancak, düzenli olarak birkaç düzine kişinin merkezi repoya erişebileceği daha büyük bir açık kaynak projesine katkıda bulunuyorum. Kişisel depolardaki tüm önemli gelişmeleri hala yapıyoruz ve hata düzeltmeleri doğrudan gönderilebilmesine rağmen kodun incelenebilmesi için özellikler için PR'ler gönderiyoruz. Ana repo sadece ana ve serbest bırakma dallarını taşıyarak dağınıklığı önler. Özellik dalları kişisel depolardadır, bu nedenle başkaları tarafından hala görülebilirler (onlar için erken PR'lar yapmak, bir özellik üzerinde çalışan ekipte başkalarını uyarır). Bu iş akışını birkaç geliştiriciden daha fazlasına sahip herhangi bir proje için önerebilirim; tek dezavantajı birden fazla uzaktan kumanda ile çalışmak zorunda.

Kod incelemelerine ve kod kalitesine değer verirseniz, geliştirici başına çatal yaklaşımı çok iyi bir yaklaşımdır. Çekme isteklerini kullanmanın güzel yanı, sorumluluğu geliştiriciden geliştiriciye kaydırmasıdır.

Geliştirici kodunu ana şubeye almak istiyor ve dahil edilmesini istiyor.

Bu, insanların taahhüt ettiği eski modelden çok farklı bir bağlam ve daha sonra gözden geçiren onlara “ah, birkaç hafta önce yaptığınız bu şey o kadar iyi değildi, şimdi düzeltin” demek zorunda kaldı.

Bu modeli şirketimizde kullanıyoruz. Kod taleplerini uygulanabilir kıldı, diğer insanların kodlarının tartışılmasını teşvik etti ve genellikle yeni araca karşı olan geliştiricilerle bile kod kalitesine yardımcı oldu. Ben de kod gözden geçirme sonra sadece 'Tamam' veya 'Tamam değil' demek yerine, gözden geçiren aktif kodu ana dalı birleştirmek zorunda, çünkü insanların daha ciddi kod değerlendirmeleri almak yaptı hissediyorum.

Her şey için tüm çatal ve dalları yapmazdım. Bu, github'daki açık kaynak mücevherleri için iyi bir modeldir, ancak modeliniz normalde değişiklikler hakkında daha yüksek bir güven düzeyine sahip olacak bir kuruluştadır.

Kaynak kontrolünün önemli bir noktası değişiklikleri görebilmeniz, geri çekebilmeniz, geri alabilmeniz vb. Durumunuzda çok sayıda çatal ve şube yapmak IMHO'yu aşırı derecede dolduruyor.

Şube gibi şeyleri rezerve ederdim: sürüm yükseltmeleri, teknoloji parçalarından birini değiştirme, 3 ay boyunca bir ana modül üzerinde çok az ortak olan bir alt modül üzerinde çalışıyor.

Bir organizasyon içinde hiç çatallanmayabilirim. Bu mod, doğası gereği kurum içi projelerden farklı olan açık kaynaklı projelere daha uygun görünmektedir.

Odağınızı test ve kod incelemelerine geçiririm. İnsanlar sınav mı yazıyor? İyiler mi? Kod incelemeleri yapılıyor mu?