Ezme çekme istekleri git'in birleştirme algoritmasını bozar mı?

Şu anda git kodunu yönetmek için VSTS kullanan bir şirket için çalışıyorum. Microsoft'un bir şubeyi birleştirmenin "önerilen" yolu, bir "squash birleşmesi" yapmaktır, yani bu şubeye ilişkin tüm taahhütler, tüm değişiklikleri içeren yeni bir taahhütte ezilir.

Sorun, bir biriktirme öğesi için bir dalda bazı değişiklikler yaparsam, hemen başka bir biriktirme öğesi için başka bir dalda değişiklik yapmaya başlamak istiyor ve bu değişiklikler ilk dalın değişiklik kümesine bağlı mı?

Bu biriktirme listesi öğesi için bir şube oluşturabilir ve ilk dalı temel alabilirim. Çok uzak çok iyi. Ancak, ikinci şube benim için bir çekme isteği yaratmanın zamanı geldiğinde, ilk şube zaten ustaya birleştirildi ve squash birleştirme olarak yapıldığı için git, bir sürü çatışmayı işaretliyor. Bunun nedeni git, ikinci dalın dayandığı orijinal taahhütleri görmemesi, sadece bir büyük squash birleştirmesini görmesi ve böylece ikinci dalı birleştirmek için ilk dalın tüm taahhütlerini tekrar oynatmaya çalışmasıdır. Squash birleşmesinin tepesi, birçok çatışmaya neden oluyor.

Benim sorum şu, bunun üstesinden gelmenin herhangi bir yolu var mı (sadece bir özellik dalını diğerine dayandırmak dışında, iş akışımı sınırlıyor) veya squash birleştirme sadece git'in birleştirme algoritmasını kırıyor mu?

Git ile taahhüt eder

• değişmez,
• ve yönlendirilmiş asiklik bir grafik oluşturur.

Ezmek, taahhütleri birleştirmez. Bunun yerine, diğer birçok taahhütten gelen değişikliklerle yeni bir taahhüt kaydeder. Yeniden pazarlama benzerdir, ancak taahhütleri birleştirmez. Mevcut bir işlemle aynı değişikliklerle yeni bir işlem kaydetmeye geçmiş yeniden yazma adı verilir . Ancak mevcut taahhütler değişmez olduğu için, bu, “alternatif bir tarih yazmak” olarak anlaşılmalıdır.

Birleştirme, ortak bir atadan yola çıkarak iki komitenin tarihinin (şubelerinin) değişikliklerini birleştirmeye çalışır.

Öyleyse geçmişinize bakalım:

                                 F  feature2
                                /
               1---2---3---4---5    feature1 (old)
              /
-o---o---o---A---o---o---S          master

A ortak atadır, orijinal özellik dalı 1–5, yeni özellik dalı F ve 1–5 ile aynı değişiklikleri içeren ezilmiş işlemdir. Gördüğünüz gibi, F ve S'nin ortak atası A'dır. Git söz konusu olduğunda, S ve 1-5 arasında bir ilişki yoktur. Bu yüzden ustayı bir tarafta S ve diğer tarafta 1–5 ile özellik2 birleştirmek çakışacaktır. Bu çatışmaları çözmek zor değildir, ancak gereksiz ve sıkıcı bir iştir.

Bu kısıtlamalar nedeniyle, birleştirme / ezme ile başa çıkmak için iki yaklaşım vardır:

• Geçmiş yeniden yazmayı kullanırsınız, bu durumda aynı değişiklikleri temsil eden birden fazla işlem alırsınız. Daha sonra olur rebase taahhüt ezilmiş üzerine ikinci özellik dalı:

                                   F  feature2 (old)
                                  /
                 1---2---3---4---5    feature1 (old)
                /
  -o---o---o---A---o---o---S          master
                            \
                             F'       feature2
  

• Veya geçmiş yeniden yazmayı kullanmazsınız, bu durumda fazladan birleştirme taahhütleri alabilirsiniz:

                                   F  feature2
                                  /
                 1---2---3---4---5    feature1 (old)
                /                 \
  -o---o---o---A---o---o-----------M  master
  

  Feature2 ve master birleştirildiğinde, ortak ata taahhüt edilecektir 5.

Her iki durumda da birleştirme çabanız olacak. Bu çaba, yukarıdaki iki stratejiden hangisini seçtiğinize bağlı değildir. Ama emin olun

• dallar kısa ömürlüdür, ana daldan ne kadar sürüklenebileceklerini sınırlamak ve
• ana öğeyi düzenli olarak özellik dalınızla birleştirir veya dalları senkronize tutmak için ana özellik dalını yeniden oluşturursunuz.

Bir ekipte çalışırken, şu anda kimin ne üzerinde çalıştığını koordine etmek yardımcı olur. Bu, geliştirilmekte olan özelliklerin sayısını küçük tutmaya yardımcı olur ve birleştirme çakışmalarının sayısını azaltabilir.

Squash birleştirme, squash tarafından kaldırılan herhangi bir taahhüt içeren şubeler için birleştirme algoritmasını bozar. Başka bir deyişle, bazlar viral. Bir dalı yeniden temellendirirseniz, o şubeye bağlı olan diğer dalları yeniden temellendirmeniz gerekir. Eğer rerere kullanırsanız , yerel deponuzda manuel olarak çözdüğünüz birleştirme çakışmalarının tekrar manuel olarak çözülmesi gerekmez, ancak bu diğer insanlar tarafından çözülen çatışmalara yardımcı olmaz.

Bu nedenle buradaki yazılmamış kuralımız, başka hiç kimse özellik dalınıza bağlı olmadığı sürece ezilmenin uygun olması, bu da belki% 90'lık bir durumdur. Aksi takdirde, düz birleştirme herkesin sorunlardan kaçınmasına yardımcı olur.