Git hızlı ileri VS hızlı ileri birleştirme yok

Git birleştirme hızlı ileri ve hızlı hızlı ileri şube birleştirmemize izin verir. Ne zaman hızlı ileri birleştirme kullanmak ve ne zaman hızlı ileri birleştirme kullanmak için herhangi bir fikir?

--no-ffEğer özellik dalı net bir fikre sahip istediğinizde seçenek yararlıdır. Bu arada hiçbir taahhütte bulunulmasa bile, FF mümkündür - yine de bazen ana hattaki her bir taahhüdün bir özelliğe karşılık gelmesini istersiniz. Bu nedenle, bir grup taahhüt içeren bir özellik dalına tek bir birim gibi davranır ve bunları tek bir birim olarak birleştirirsiniz. Şube ile birleştirme özelliği yaptığınızda geçmişinizden anlaşılır --no-ff.

Böyle bir şeyi umursamıyorsanız - muhtemelen mümkün olduğunda FF ile kurtulabilirsiniz. Böylece daha fazla svn benzeri iş akışı hissine sahip olacaksınız.

Örneğin, bu makalenin yazarı bu --no-ffseçeneğin varsayılan olması gerektiğini düşünüyor ve muhakemesi yukarıda özetlediğim şeye yakın:

"Unsur" dalında bir dizi küçük taahhüdün topluca yeni bir unsur oluşturduğu durumu göz önünde bulundurun: "git merge feature_branch" olmadan "yaparsanız --no-ff, Git geçmişinden taahhüt nesnelerinden hangilerinin birlikte olduğunu görmek mümkün değildir bir özellik uygulandı — tüm günlük mesajlarını manuel olarak okumalısınız.Tüm bir özelliği (yani bir grup taahhüt) geri döndürmek, gerçek bir baş ağrısıdır (eğer --no-ffkullanılmıyorsa), oysa --no-ffbayrak kullanılırsa kolayca yapılabilir [çünkü sadece bir taahhüt]. "

Projede yaygın olarak görülen bir örnek verebilirim.

Burada, seçenek --no-ff(yani gerçek birleştirme ) birden çok ebeveynle yeni bir taahhüt oluşturur ve daha iyi bir geçmiş takibi sağlar. Aksi takdirde, varsayılan olarak --ff( hızlı ileri birleştirme ) kullanılır.

$ git checkout master
$ git checkout -b newFeature
$ ...
$ git commit -m 'work from day 1'
$ ...
$ git commit -m 'work from day 2'
$ ...
$ git commit -m 'finish the feature'
$ git checkout master
$ git merge --no-ff newFeature -m 'add new feature'
$ git log
// something like below
commit 'add new feature'         // => commit created at merge with proper message
commit 'finish the feature'
commit 'work from day 2'
commit 'work from day 1'
$ gitk                           // => see details with graph

$ git checkout -b anotherFeature        // => create a new branch (*)
$ ...
$ git commit -m 'work from day 3'
$ ...
$ git commit -m 'work from day 4'
$ ...
$ git commit -m 'finish another feature'
$ git checkout master
$ git merge anotherFeature       // --ff is by default, message will be ignored
$ git log
// something like below
commit 'work from day 4'
commit 'work from day 3'
commit 'add new feature'
commit 'finish the feature'
commit ...
$ gitk                           // => see details with graph

(*) Burada newFeatureşube yeniden kullanılırsa, yeni bir şube oluşturmak yerine --no-ffgit'in yine de birleştirme yapmak zorunda kalacağını unutmayın . Bu, hızlı ileri birleştirme işleminin her zaman uygun olmadığı anlamına gelir.

Geliştirme ortamı üzerinde çalıştığımızda ve kodumuzu hazırlama / üretim koluyla birleştirdiğimizde Git hızlı ileri almak daha iyi bir seçenek olamaz. Genellikle tek bir özellik için geliştirme dalında çalışırken birden fazla taahhüdümüz olur. Değişiklikleri birden fazla işlemle izlemek daha sonra rahatsız edici olabilir. Git'i ileriye doğru kullanarak hazırlama / üretim dalıyla birleştirirsek, sadece 1 taahhüdü olacaktır. Şimdi özelliği geri almak istediğimizde, yalnızca bu taahhüdü geri al. Hayat kolay.

Ayrıca, kodun günün sonunda yerleştirildiği kişiselleştirilmiş özellik dallarına sahip olmak da mümkündür. Bu, gelişmeyi daha ince bir şekilde izlemeye izin verir.

Usta gelişimini çalışmayan kodla kirletmek istemem, böylece - no-ff yapmak sadece aradığı şey olabilir.

Bir yan not olarak, kişisel bir dalda çalışma kodunun işlenmesi gerekli olmayabilir, çünkü tarih, git rebase -iaynı dalda başka kimse çalışmadığı sürece sunucuya yeniden yazılabilir ve zorlanabilir.