Büyük çekme talebi ile başa çıkmak

Şu anda git iş akışı kullanan bir ekiple bir proje üzerinde çalışıyorum. Oldukça basit, master konuşlandırılabilir bir durumda olmalı ve dallar özellikler ve düzeltmeler oluşturmak için kullanılır. Tamamlanan ve test edilen bir özelliğe veya hata düzeltmesine sahip olduğumuzda, bunu mümkün olan en kısa sürede master'a taşıyoruz. Fikir şu ki, dalların onları ustalıkla birleştirmeyi kolaylaştırmak için mümkün olduğunca küçük olması gerekiyor. Ana şubeye gönderilen herhangi bir kodun konuşlandırılabilir bir durumda olması ve testleri geçmesi gerektiği konusunda bir politikamız var.

Geliştiricilerden birinin tek bir dalda çok fazla iş (birkaç ay değerinde) yaptığı ve bu dalın henüz efendiye tekrar birleştirilmediği bir durumumuz var. Şimdi bu dalda birkaç ayrı özellik ve bir sürü taahhüt var, aslında bu dalın zaten birkaç kez birleştirilmesi gerekiyordu, ancak şimdiye kadar olmadı. Kodun çoğu, master ile birleştirilebilen birim testleri ile iyi durumdadır, ancak en son değişiklikler kesinlikle tamamlanmadığı ve test edilmediği için olmamalıdır.

Bir dalın diğerlerinden çok uzakta olduğu böyle bir durumla başa çıkmanın en iyi yolu nedir? Gelecekte şubelerin çok fazla sayıda taahhüdü ustadan uzaklaştırmasını nasıl önleyebiliriz?

Birleştirmeden birkaç ay giden geliştiricinin düzeltmesine izin verin. Belki birleştirmek için büyük bir kod parçası alabilirler, belki birer birer birleştirmek için bir sürü küçük parça alabilirler. Her durumda, soruna neden oldukları için sorunu çözmek için ayak işlerini yapıyor olmalılar.

Bir dalın diğerlerinden çok uzakta olduğu böyle bir durumla başa çıkmanın en iyi yolu nedir?

Genel olarak, endişelenmeyin: diğer geliştiricinin sorunu. İki dal ise gerçekten Ayırmak birbirinden çok uzak, o zaman gerçekten aynı projenin parçası artık değildir ve bir defacto çatal var. Açık kaynak kodlu bir projeyse, bu bir problem bile olmayabilir.

Bu geliştirici gerçekten parlaksa ve kodları ekibin geri kalanından daha iyi / daha akıllı / daha önemliyse, o zaman onların yerine probleminiz haline getirmeye değer. Aksi halde değil.

Değişmez soruyu cevaplamak için: bu tür bir durumla başa çıkmanın en iyi yolu, bu tür bir duruma girmemektir.

Gelecekte şubelerin çok fazla sayıda taahhüdü ustadan uzaklaştırmasını nasıl önleyebiliriz?

Herkesin aylarca birleşme olmadan giden geliştiricinin, neden oldukları sorunu düzeltmek zorunda olduğunu fark ettiğinden emin olun. Herkesin sık sık ustalaşmanın nadiren olduğundan daha kolay olduğunu bildiğinden emin olun, çünkü daha az değişiklik çatışmalar için daha az fırsat anlamına gelir.

İnsanların, diğer insanların değişiklikleriyle güncel kalmak için ustadan çekebileceklerini bildiklerinden emin olun.

"Her gün birleşirseniz, aniden çözülmesi zor olan büyük çatışmaların olduğu noktaya gelmezsiniz." --Linus Torvalds

Bu alıntı Google'da yaptığı bir konuşmadan , transkript ve işte video .

Bunu bildiğiniz bir taahhüdünüz varsa ve önceki tüm taahhütlerin iyi test edildiğini ve birleştirilmesi gerekiyorsa, bu son iyi taahhütten ayrılmanız ve yeni şubeyi usta ile birleştirmeniz yeterlidir.

Birleştirmek istediğiniz bazı taahhütleriniz varsa, ancak üretime hazır olmayan diğer taahhütlerle serpiştirilmişse, 2 olasılık görüyorum:

1. Yeni şube oluşturun ve kiraz iyi taahhütler seçin, usta ile birleşin.
2. İstenmeyen taahhütleri en üste çıkarmaya çalışın (belki sadece güvenli olmak için yeni dalda).

Önleme yöntemlerine gelince, "Bir hafta içinde usta ile birleşmeyen bir ay boyunca pizza sipariş edecek" gibi komik takım kurallarını tanımlamaya çalışın.

İlk olarak, @Maciej Chalpuk'un önerdiği gibi birleştirilebilen veya kirazla toplanabilen ayrı taahhütlerin olup olmadığına bakın. Durum böyleyse, durum o kadar da kötü değildir ve gelecekte bu konuda fazla endişelenmem.

Bununla birlikte, gerçek durum, aynı taahhütler dahilinde, tek bir dalda aynı anda birden fazla özelliğin geliştirilmiş olması durumunda, başa çıkmak çok daha büyük bir acı haline gelir. Neyse ki, önleme yöntemi yerleşiktir: geliştiricinin her bir özellik için değişiklikleri ayrı dallara ayırmasını ve bunları birleştirmeden önce istekleri çekmesini gerektirir. gelecek.

Özellikleri ayırma işlemi tamamen manueldir. Ana daldan yeni dallar oluşturun ve onunla ilişkili mega daldan gelen değişiklikleri kopyalayın. Derleme, özelliği test etme, çekme ve çekme isteği gönderme. Kod değişiklikleri ne kadar az karışırsa, o kadar kolay olur. Eğer hepsi için tek bir yöntem hack ederse, iyi eğlenceler. Bir daha yapmayacak.

İşte basit bir çözüm.

Bu kişinin uyguladığı özellikleri izleyin ve her dalda özellik başına güncellenen her bir işleme gidin. Bu taahhüdü alın ve ana repo ile birleştirin.

Bunu örnek olarak yıkayım.

Izin: A dalını ana daldan olmak A + = Dal A + yeni özellik 1 Dal A ++ = Dal A + yeni özellik 2 vb.

Yapmanız gereken şuraya geri dönmek: Branch A +

A + Şubesini alın ve Master ile birleştirin.

Şimdi A ++ Dalına gidin ve (Master + Branch A +) ile birleştirin.

Kararlı olan son A + ... + Şubesine ulaşana kadar tekrarlayın.

Bu yöntem ilk başta karşı sezgisel gelebilir, ama sen ustayla kendi başına her bir ayrı yeni bir özellik birleştirme halinde bunun "ana dal arasında geçiş yapmak kolaylaşır ilave özellik başına "

Gelecekte şubelerin çok fazla sayıda taahhüdü ustadan uzaklaştırmasını nasıl önleyebiliriz?

Yukarıdaki çözümümün gelecekte hangi yöntemi kullanmanız gerektiğini gösterdiğini düşünüyorum. Her dal için bir özellik başına veya görev yöntemi başına gidin.

Ben bir yaklaşım kullanmanızı öneririm:

master öncesi ve master

master: Final / üretim seviyesi. Sık sık değiştirilmez. Her zaman kararlı kabul edilir

master öncesi: mevcut koda yeni bir özelliğin eklendiği alandır. Mevcut kod tabanı ile çalışmak için kapsamlı bir şekilde test edilmiştir ve diğer branşların yeni özellik uygulaması için çatallanabileceği yerdir.

Ayrıca özellikleri bir araya getirmeyi ve sürüm hedeflemeyi hedeflemeyi de denemelisiniz.

Sürüm hedefleme: Ana dal için yer tutucu olarak işlev görecek rastgele bir sayı belirtin. "V1.0.0'da X, Y, Z özelliklerini elde etmek isteyeceğiz. V1.0.0'da şu işlevlerin tümü de mevcut olacak: ..."

Master'a karşı bir versiyonu koruyarak, "master" ı her zaman sabit ve üretime hazır tutmanın bir yolu olabilir.

Büyük çekme talebi sorununu çözmek bir şeydir ve bununla ilgili bazı iyi cevaplar vardır. Ancak güncel olmayan şubelerle uğraşmak için, ekip çalışmasıyla ilgili süreçlerinizi tekrar gözden geçirmek isteyebilirsiniz.

Agile veya SCRUM çerçevesi içinde çalışıyorsanız, ekip gerçekten özelliğin neden yinelenmediğini / sprint'in bir parçası olarak tamamlanmadığını ve birleştirilmediğini sormalıdır. Yinelemeye sığmayacak kadar büyükse, daha küçük parçalara bölünmüş olmalıydı.

Ayrıca, kod sahibi olma sorununu da gündeme getiriyor - ekibinizde, bireysel geliştiriciler ayrı ayrı kendi çalışmalarına sahip mi, yoksa tüm ekip öğelerin yapılmasını sağlamak için birlikte çalışıyor mu?

Tabii ki, yukarıdaki takımınızın bir tür şirket yapısı içinde olduğunu varsayar. Bu gönüllü katılımcılar ile açık kaynaklı bir proje ise, bu başka bir hikaye. Genellikle bu tür projeler iş akışları üzerinde daha gevşek bir kontrole sahiptir, ancak kabul edilebilir çekme talepleri üretme sorumluluğu bireysel katılımcılara daha sık düşer.

Birçok yönden bu bir süreç sorusu haline gelir. Belki ihtiyaç duyduğunuz süreç, uzun süren, birleştirilmemiş şubeler için periyodik olarak (haftalık? Aylık?) Kontrol edilmesini içerir. Bazı araçlar bunu görsel olarak kontrol etmeyi kolaylaştırır; Örneğin github'da "şubeler" bağlantısını ziyaret edin ve her bir dalın ne kadar ilerisinde / arkasında olduğunu gösterir.