Git-flow tarafından uygulanan başarılı Git dallanma modelini benimsemeye çalışıyoruz . Şimdi, biri en son kararlı sürüm ve diğeri sonraki ("önizleme") sürüm için olmak üzere en az iki yayın dalı üzerinde çalışıyoruz. Anlamadığım şey, neden tüm sürümlerin ana bilgisayara "doğrusallaştırılmış" ve orada etiketlenmiş gibi göründüğü . Sürümleri neden sürüm dallarında etiketlemiyorsunuz? Neden usta ? Ya da neden bir geliştirme dalı ve bunun için master kullanmıyorsunuz ?
Yanıtlar:
Git-flow modelinde, "en son yayınlanan" sürümünüz ile eşlenirken master"önizleme sürümünüz" bir git-flow releasedalına eşlenir . Gerçek sürüm gerçekleştiğinde , çatallanır developve sonunda birleştirilir master. Daha sonra bu sizin "en son sürümünüz" olacak ve genellikle git-flow hotfixdallarını kullanarak bu sürüm için yalnızca hataları düzelteceksiniz . Bu şekilde, masterher zaman en son yayınlanan sürümünüzün en kararlı durumunu temsil eder.
Eski sürümler için hataları düzeltmek veya orada başka bir geliştirme yapmak istiyorsanız support, uygun commit'den bir dal çatallayacaksınız master( orada oluşturulmuş tüm sürümlere sahip olacaksınız ). supportşubeler hala deneyseldir ( belgelere göre ) ve iyi belgelenmemiştir. Ancak komut satırından da görebileceğiniz gibi yardım:
usage: git flow support [list] [-v]
git flow support start [-F] <version> <base>
bu dallar yeni başlatılmıştır ve masterne de geri birleştirilmeleri amaçlanmamıştır develop. Bu genellikle iyidir, çünkü müşteriler tarafından "eski" sürümlerde uygulanması istenen "eski" sürümler veya özellikler için yapılan düzeltmeler geri dönülemez veya geri dönmemelidir master. Hala düşünüyorsanız, ana geliştirme hattınıza ( masterve ile gösterilen develop) bir düzeltme eklemek istiyorsanız , sadece bir başlayın hotfix, değişikliklerinizi seçin ve hotfix.
git flow supportdeneysel olarak işaretlenmemiş.
Dallara biraz fazla vurgu yapan çoğunlukla zihinsel bir modele benziyor. Kabul ediyorum, yayınladığınız taahhütleri ana olarak birleştirmek yerine etiketleyebilirsiniz.
Yine de resim güzel. Her şeyi ana olarak birleştirmek, sürüm etiketlerinin grafiğin her yerine dağılması yerine geçici sırayla sürümlerin açık bir göstergesini verir.
Yine de bu modelin eski sürümlerde hata giderme için çalışmadığını düşünüyorum. Düzenli siparişi bozuyor.
Sorunuzu cevaplamak için: Sanırım bu, bazı durumlarda basit bir zihinsel model oluşturan bir dizi kuraldır. Tüm kurallar tamamen teknik açıdan anlam ifade etmiyor ama bu onları kötü yapmıyor. Zihinsel modeller onlar için iyi olur.
supportşubeler eski sürümlerde hata düzeltmek için tasarlanmıştır, ancak yine de "deneysel" olarak etiketlenmiştir.
Ben şahsen söz konusu git-akışının aşırı karmaşık olduğunu düşünüyorum.
GitHub kullanıyorsanız GitHub flow(Scott Chacon tarafından açıklandığı gibi) deneyin .
Özellikle birden çok özellik üzerinde işbirliği, kod incelemesi için kullanışlıdır ve bunu Commit Status API.
GÜNCELLEME : GitHub Flow ™ 'un yeni bir resmi web sitesi var
GÜNCELLEME 2 : GitHub Flow ™ için yeni bir resmi (ve basitleştirilmiş) GitHub Kılavuzu var: https://guides.github.com/introduction/flow/
master, eserin kronolojisinin bir anormalliği ile birleştirilemez .
supportdalları içindir. Ama haklısın, bu tür sürümlerin yeniden birleştirilmemesi gerçekten bir anormallik, ki bu da master- benim anlayışıma göre - tüm prodüksiyon sürümlerini içermeli.
Benim durumumda, aynı yazılımın temelleri aynı olan ancak her sürümün bazı farklı özellikleri olan iki sürümüne sahibim.
Bu yüzden iki tane oluşturuyorum worktree, bunun anlamı, ana birimin yanında iki ilgili uzun süreli dal oluşturmaktır.
$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master
O zaman bende:
$git branch
master # base stuff here
version-silver # some normal features
version-gold # some better features
Bir depo var ama yukarıdaki her dal için yan yana 3 ayrı klasörüm var. Ve ustada ortak değişiklikleri yapın. daha sonra diğer iki sürümle birleştirin.
cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project
Her sürümün belirli değişiklikleri ilgili klasöre de gidecek ve her projedeki çalışmalar izole edilecek ve IDE'nin kafası karışmayacak.
Umarım yardımcı olur.
@Mot'a tamamen katılıyorum.
Aynı soruları duymak güzel.
Ekibimiz ayrıca Successfull modelinden daha fazla Evrensel dallanma modeli için avlandı . Örneğin yukarıda bahsedildiği gibi @Mot - ana fikir, ayrık * .git deposunda release- * dallarını desteklemek için fazladan depolardan kaçınmaktır, örneğin kararlı sürümler için kernel.org tarafından yapıldığı gibi. Ancak kernel.org bunu, indirilen boyutları en aza indirmek için yapıyor sanırım.
Bana göre , geliştirme için ana hat olarak ustaya sahip olmak daha temiz görünüyor .
Ayrıca bazı çakışma release- * modelini birleştirme için usta ve düşüncesi ile sonradan etiketleyerek
Ana üzerinde bir taahhüt olduğunda yazılımımızı otomatik olarak oluşturmak ve üretim sunucularımızda kullanıma sunmak için bir Git kanca komut dosyası kullanmak
neden bitirme (birleştirme ve etiketleme) atomik bir işlem değildir:
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
ve git hook otomatik sürüm oluşturma desteği ile derlemeye başlarsa:
$git describe --tags --long >.ver
o zaman yanlış bir sürümün aşağıdakiler için oluşturulması mümkündür:
$ git merge --no-ff release-1.2
Successfull'da sürümlemenin bazı bump sürüm sürecini tanıttığını biliyorum, ancak bu otomatik değil.
Özetlemek gerekirse - sürümler için şube modeline sunduğumuz temel farklar - * birleştirme ve etiketleme: - Dalını oluşturmada sürümü etiketleme - gelecekte bunların bakımını sağlamak için sürümün dalını koruyun
Ana şube HER ZAMAN üretim kod tabanınızı temsil etmelidir, bu nedenle her zaman bir üretim sürümünden hemen sonra kodu ana olarak birleştirirsiniz.
Etiketleme, bir üretim sürümüne giren tam kodu "ezberlemek" için kullanılır, böylece daha sonra geri dönebilir ve bir şeyler ters giderse kodu analiz edebilirsiniz.
Bu teorik olarak, kodunuzu ana dalda yeniden birleştirdikten sonra sürüm dalında veya ana dalda etiketlemeniz önemli olmamalıdır. Ben şahsen sürüm dalındaki kodu etiketlemeyi tercih ederim, çünkü bu tam olarak derleme / yayınlama işlemine giren koddur (birleştirme ile bir şeylerin ters gidebileceğini varsayarak).
Geliştirme şubesi konseptiyle ilgili sorun, tek iş parçacıklı olmasıdır. Bu başlıkta Brendan, bir geliştirme dalı konseptini içeren bir stratejiden bahsetti.