Düzeltmeleri ele alırken birden fazla etkin sürüm için uygun Git iş akışı

Ürünümüz için en uygun olan Git iş akışını seçmeye çalışıyorum. İşte parametreler:

• Yılda birkaç büyük yayın yapıyoruz, en fazla 10 diyelim.
• Ürünümüzün aynı anda etkin birden çok sürümüne sahibiz (bazıları v10.1’de, bazıları v11.2’de vs.)
• Aynı anda birden fazla sürüm üzerinde çalışabilmemiz gerekiyor (v12.1 üzerinde çalışıyor olabiliriz, ancak sürümün sonuna geldikçe v12.2'de aynı anda çalışmaya başlıyoruz)
• Kritik hatalar bulunduğunda, sürümleri düzeltebilmemiz gerekir.

Şimdiye kadar, işte işe yarayabileceğini düşündüğüm yol:

• Tek bir uzaktan repo kullanılır
• Master'dan şube 12.1 oluşturun
• 12.1'e dayalı özellik dalları oluşturun, onları işleyin ve tekrar 12.1'e birleştirin,
• Gelecek sürüm için çalışmaya başlamamız gerektiğinde, 12.1 tabanlı yeni bir şube 12.2 oluşturun.
• Ondan sonra, 12.1 için bir özellik üzerinde çalışırken, 12.1'den dal oluşturun, değişiklik yapın ve hem 12.1 hem de 12.2'de birleştirin,
• 12.2 için bir özellik üzerinde çalışıyorsanız, 12.2'den şube oluşturun, değişiklik yapın ve yalnızca 12.2'ye birleştirin,
• Sürüm 12.1 tamamlandığında, bunu master ile birleştirin ve master şubesini 12.1 ile etiketleyin
• Bir düzeltmeye ihtiyaç duyulursa, ihtiyacı olan en eski sürümden bir düzeltme dalı oluşturun, değişiklik yapın ve etkilenebilecek sürümler ve gelecek sürümler için tüm sürüm dallarına geri dönün; En son kararlı sürüm dalı etkilendiyse, ana birimde birleştirin.

Birkaç kaygım var:

• Düzeltmeleri eski dallardan yeni dallara dahil etmenin, özellikle çok fazla çakışan değişiklik olsaydı sorunsuz bir süreç olacağından emin değilim; Uyuşmazlık olacağına benzeyen durumlarda her dalda manuel olarak düzeltmek daha akıllıca olur mu?
• Gördüğüm iş akışı modelleri, serbest bırakma dallarını çok canlı tutmuyor gibi görünüyor, bir kez yapıldığında, serbest bırakma master ile birleştiriliyor, etiketleniyor ve çıkartılıyor. Bununla ilgili sorunum, eğer sahip olduğum usta etiketler varsa, bir dalda düzeltmeyi daha kolay gözüküyorsa serbest bırakma durumunu nasıl yöneteceğimi bilmiyorum ve daha sonra her zaman geri dönebileceğim bir sürüm var. Bu son düzeltmeyi içerir (sürümdeki düzeltmeleri bile etiketleyebilirim). Master'a geri dönebilmemin bir yolu olduğundan ve bir şekilde düzeltmeler uygulanmış sürümün bir kopyasına sahip olduğundan ve bu etiketi güncellediğinden emin değilim.

Gözden geçirmiş olabileceğim veya belirtmiş olduğum şartlar doğrultusunda işleri başarmanın daha iyi yollarına ilişkin yorumlar takdir edilmektedir.

Her büyük sürümde (12.0.0) dallanıyor, daha sonra her birinde (12.1.0) küçük güncellemeler ve düzeltmeler var (12.2.1). Doğru?

Serbest bırakma dallarını GitFlow'da bıraktıktan sonra canlı tutmamanızın belirli bir nedeni yoktur; bunun dışında birden fazla farklı dal arasında değişen değişiklikleri uzun süre koordine etmenin herhangi bir model için zor olmasından başka bir neden yoktur. Sanırım, GitFlow da bir sonrakini geliştirirken tek bir canlı yayın sağlayan ürünler için daha fazla modellenmişti.

GitFlow'a sadık kalacağım ve birkaç değişiklik yapacağım;

Ana şubeyi atla. Şimdiye kadar pratik bir kullanımım olmadı ve çalışma şeklinizdeki doğrusallığını yitirirdi. Geliştirme konusundaki bir sonraki önemli sürümde gelişmeye devam edin. Master'ı tutmaya karar verirseniz, master'a serbest bırakma etiketlerini koymayın, gönderdiğiniz ikiliyi üreten salma dalındaki son işlemi yapın.

Gelişim için onları tekrar birleştirdikten sonra salma dallarını atmayın. Bunun yerine bir sonraki küçük sürüm ve olası sıcak düzeltmeler için onları etrafta tutun. Bir sürümü desteklemeyi hiç bırakmazsanız, onları silmenin iyi olduğunu düşünüyorum. Serbest bırakma dallarını ana bileşenlerinden sonra adlandırabilir, serbest bırakma / 12 ve sonra bırakarak serbest bırakma dalları, serbest bırakma / 12.1, serbest bırakma / 12.2. Bu paralellik düzeyi hakkında çok fazla endişelenmek zorunda kalmamıştım, ama muhtemelen denerim. Her büyük sürüm şubesini, bu durumda kendi GitFlow ortamı olarak düşünebilirsiniz.

Gelecekteki birkaç büyük sürümün özelliklerine paralel olarak aynı anda çalışmanız gerekiyorsa, belki de bir sonrakini (13) geliştirmeye devam etmelisiniz ve daha sonraki sürümler için (14, 15) ek "develop-N" dallarında tutmalısınız. . Genel olarak bakımı çok zor gibi görünüyor, ancak mümkün olacak.

Asıl probleminiz için olası bir çözüm ( “Aynı anda birden fazla sürümde çalışabilmemiz gerekir [...]» )git worktree add <path> [<branch>]

Bir git deposu birden fazla çalışan ağacı destekleyebilir ve aynı anda birden fazla şubeye göz atmanızı sağlar.
İle git worktree add, yeni bir çalışma ağaç depo ile ilişkilidir.

Bu yeni çalışma ağacına " git init" veya " git clone" tarafından hazırlanan "ana çalışma ağacı" yerine "bağlantılı çalışma ağacı" denir .
Bir havuzda bir ana çalışma ağacı (eğer çıplak bir havuz değilse) ve sıfır veya daha fazla bağlantılı çalışan ağaç vardır.

Ayrıntılı bir giriş için bu SO cevabına bakınız git worktree.

Gitflow'u bildiğini söylemiştin. Senaryonuz için eklemenizi öneririm. Eski sürümleri desteklemek için geliştirme şubenizden şubeler oluşturmanız gerekecektir. Bu eski sürümlerin ayrıca kendi yayın / ana dallarına ve düzeltme dallarına sahip olmaları gerekir. Destek şubelerinizi periyodik olarak yeni destek şubeleri ve geliştirme şubesiyle birleştirmeniz gerekecektir.

Büyük versiyonların gelişimi değiştikçe, bu zorlaşmaya devam edecektir. Bunun için gümüş mermi yok. Bazen manuel olarak değişiklik yapmak daha kolay olur. Eski sürümleri korumanın maliyeti artacak ve bir noktada buna değmeyecek.

Her şey eski sürümlerinde ne tür değişiklikler yaptığınıza bağlı. Yalnızca hata düzeltme özelliği varsa, birleştirilmesi nispeten kolaydır. Yeni özellikler eklemeye çalışırsanız, bu zor olacaktır.