Hızlı ileri birleştirme, kısa ömürlü dallar için mantıklıdır, ancak daha fazlası karmaşık bir tarihte , hızlı ileri birleştirme, tarihin anlaşılmasını kolaylaştırabilir ve bir grup taahhüdü geri almayı kolaylaştırabilir.
Uyarı : Hızlı yönlendirmenin potansiyel yan etkileri de vardır. Lütfen https://sandofsky.com/blog/git-workflow.html dosyasını inceleyin, ikiye veya suçu kıran "kontrol noktası taahhütleri" ile "no-ff" kullanmaktan kaçının ve varsayılan yaklaşımınız olup olmadığını dikkatlice düşünün master.
(Dan nvie.com , Vincent Driessen , post " Başarılı Git dallanma modeli ")
Geliştirilmiş bir özelliği geliştirme üzerine dahil etme
Biten özellikler, önümüzdeki sürüme eklenecek şekilde geliştirme dalında birleştirilebilir:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
--no-ffBayrak birleştirme ileri sarma ile yapılabilir bile, her zaman yeni bir nesne işlemek oluşturmak için birleştirme neden olur. Bu, bir özellik dalının tarihsel varlığı hakkında bilgi kaybını önler ve birlikte özelliği ekleyen tüm taahhütleri gruplandırır.
Jakub Narębski da söz yapılandırmamerge.ff :
Varsayılan olarak Git, geçerli taahhüdün torunu olan bir taahhüt birleştirilirken fazladan birleştirme taahhüdü oluşturmaz. Bunun yerine, mevcut dalın ucu hızlı iletilir.
Olarak ayarlandığında false, bu değişken Git'e böyle bir durumda fazladan birleştirme taahhüdü oluşturmasını söyler ( --no-ffkomut satırından seçeneği vermekle eşdeğerdir ).
' only' Olarak ayarlandığında , yalnızca bu tür hızlı ileri birleştirme işlemlerine izin verilir ( --ff-onlykomut satırından seçeneğin verilmesine eşdeğerdir ).
Hızlı ileri sarma varsayılan ayardır çünkü:
- Kısa ömürlü dalların Git'te kullanımı ve kullanımı çok kolaydır
- kısa ömürlü dallar genellikle o dalda serbestçe yeniden düzenlenebilen birçok taahhüdü izole eder
- bu taahhütler aslında ana dalın bir parçasıdır: bir kez yeniden düzenlendikten sonra ana dal onları dahil etmek için hızlı bir şekilde yönlendirilir.
Ancak, bir konu / özellik dalında yinelenen bir iş akışı bekliyorsanız (yani birleştiririm, bu özellik dalına geri dönüp daha fazla taahhüt ekliyorum), o zaman ana dalda yalnızca birleştirmeyi dahil etmek yararlı olur. özellik dalının tüm ara taahhütleri.
Bu durumda, bu tür bir yapılandırma dosyasını ayarlayabilirsiniz :
[branch "master"]
# This is the list of cmdline options that should be added to git-merge
# when I merge commits into the master branch.
# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.
# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.
mergeoptions = --no-commit --no-ff
OP yorumlarda şunları ekliyor:
[Kısa ömürlü] dallar için ileriye doğru bir anlam görüyorum, ama varsayılan eylemi yapmak git'in sizi [kısa ömürlü] dallara sahip olduğunu varsayar. Makul?
Jefromi cevapları:
Bence şube ömrü kullanıcıdan kullanıcıya büyük farklılıklar gösteriyor. Bununla birlikte, deneyimli kullanıcılar arasında, muhtemelen çok daha kısa ömürlü şubelere sahip olma eğilimi vardır.
Bana göre, kısa ömürlü bir branş, belirli bir işlemi kolaylaştırmak için (yeniden basma, muhtemelen veya hızlı yama ve test etme) oluşturmak için oluşturduğum ve sonra bitirdiğimde hemen silin.
Bu, büyük olasılıkla çatallandığı konu dalına emilmesi ve konu dalının bir dal olarak birleştirilmesi gerektiği anlamına gelir . Kimsenin bu özelliği uygulayan bir dizi taahhüt oluşturmak için dahili olarak ne yaptığımı bilmesine gerek yok.
Daha genel olarak şunu ekliyorum:
gerçekten geliştirme iş akışınıza bağlıdır :
- doğrusal ise, bir dal mantıklıdır.
- Özellikleri izole etmeniz ve üzerinde uzun süre çalışmanız ve tekrar tekrar birleştirmeniz gerekiyorsa, birkaç dal mantıklıdır.
Bkz. " Ne zaman dallanmalısınız? "
Aslında, Mercurial şube modelini düşündüğünüzde, her depoda çekirdek bir daldır ( anonim kafalar, yer imleri ve hatta adlandırılmış dallar oluşturmanıza rağmen )
Bkz. "Git ve Mercurial - Karşılaştır ve Kontrast" .
Mercurial, varsayılan olarak, terminolojisinde "kafa" olarak adlandırılan anonim hafif kodlayıcılar kullanır.
Git, uzak depodaki dalların adlarını uzaktan izleme dallarının adlarıyla eşleştirmek için bilinçli olarak adlandırılan dallar kullanır.
Git, sizi şubeleri adlandırmaya zorlar (" bağımsız bir HEAD " adı verilen bir durum olan tek bir adlandırılmamış dal hariç ), ancak bunun konu dalı iş akışı gibi dal ağır iş akışlarıyla daha iyi çalıştığını düşünüyorum. tek bir depo paradigmasında çoklu dallar.
no-ffikiye veya suçu kıran "kontrol noktası taahhütleri" ile " 'den kaçının .