Git Merge ve Git Rebase'e Giriş: Ne Yapar ve Ne Zaman Kullanır?

Bir Geliştirici olarak, çoğumuzun Birleştirme ve Rebase arasında seçim yapmak zorundayız. İnternetten aldığımız tüm referanslarla, herkes "Rebase'i kullanma, ciddi sorunlara neden olabilir" diye inanıyor. Burada birleştirme ve yeniden oluşturma işleminin ne olduğunu, neden kullanmanız gerektiğini (ve kullanmamalıyız) ve nasıl kullanılacağını açıklayacağım. böyle yaparak.

Git Birleştirme ve Git Rebase aynı amaca hizmet eder. Birden fazla daldan gelen değişiklikleri bir taneye entegre etmek için tasarlanmıştır. Nihai hedef aynı olsa da, bu iki yöntem farklı şekillerde bunu başarır ve daha iyi bir yazılım geliştiricisi olduğunuzda farkı bilmek faydalıdır.

Bu soru Git topluluğunu böldü. Bazıları her zaman yeniden dirilmeniz gerektiğine, bazıları ise her zaman birleşmeniz gerektiğine inanıyor. Her iki tarafın da bazı inandırıcı faydaları vardır.

Git Birleştirme

Birleştirme, sürüm kontrol sistemlerini kullanan geliştiriciler için yaygın bir uygulamadır. Dallar sınama, hata düzeltmeleri veya başka nedenlerle oluşturulmuş olsun, birleştirme başka bir konuma değişiklik yapmayı taahhüt eder. Daha spesifik olmak gerekirse, birleştirme bir kaynak dalının içeriğini alır ve bunları bir hedef dalla bütünleştirir. Bu süreçte sadece hedef şube değiştirildi. Kaynak dalı geçmişi aynı kalır.

Master Birleştir -> Özellik dalı

Artıları

  • Basit ve tanıdık
  • Tarihin tamamını ve kronolojik düzeni korur
  • Şube içeriğini korur

Eksileri

  • Taahhüt tarihi çok sayıda birleştirme komisyonu tarafından kirlenebilir.
  • Git bisect kullanarak hata ayıklama zorlaşabilir

Nasıl yapılır

Ödeme ve birleştirme komutlarını kullanarak ana dalı özellik dalında birleştirin.

$ git ödeme özelliği
$ git birleştirme ustası
(veya)
$ git master birleştirme özelliği

Bu, her iki dalın geçmişini tutan özellik dalında yeni bir “Birleştirme taahhüdü” yaratacaktır.

Git Rebase

Rebase, bir şubeden diğerine değişiklikleri entegre etmenin başka bir yoludur. Rebase, tüm değişiklikleri tek bir "yama" olarak sıkıştırır. Ardından yamayı hedef dalına entegre eder.

Birleşmeden farklı olarak, yeniden yapılanma tarihi düzleştirir, çünkü tamamlanan işi bir daldan diğerine aktarır. Bu süreçte istenmeyen tarih ortadan kalkar.

Rebases, değişikliklerin hiyerarşinin tepesinden aşağıya doğru nasıl geçmesi gerektiği ve birleşimler nasıl yukarı doğru geri akmaları gerektiğidir.
Özellik dalını yeniden usta haline getirme

Artıları

  • Potansiyel olarak karmaşık bir tarihi kolaylaştırır
  • Tek bir taahhüdü değiştirmek kolaydır (örneğin, bunları geri almak)
  • Birleşmeleri engeller, meşgul şubelerle meşgul depolarda “gürültü” yapar
  • Ara taahhütleri, DevOps ekipleri için faydalı olabilecek tek bir taahhüt haline getirerek temizler.

Eksileri

  • Özelliği bir avuç işleve indirgemek içeriği gizleyebilir
  • Ekip olarak çalışırken, kamu depolarını yeniden inşa etmek tehlikeli olabilir
  • Daha fazla iş: Özellik şubenizi her zaman güncel tutmak için yeniden kullanma özelliğini kullanma
  • Uzak dallarla yeniden düzenleme işlemi zorlamanız gerekir. İnsanların karşılaştığı en büyük sorun, zorlamaya zorlamalarıdır, ancak git itme varsayılanını ayarlamadılar. Bu, hem yerel hem de uzaktan aynı adı taşıyan tüm şubelerin güncellenmesine ve bununla başa çıkmak için korkunç bir sonuçtur.
Yanlış ve yeniden istenmeden yeniden yazarsanız, geçmişi ciddi sorunlara yol açabilir, bu yüzden ne yaptığınızı bildiğinizden emin olun!

Nasıl yapılır

Aşağıdaki komutları kullanarak özellik dalını ana dal üzerine yeniden asın.

$ git ödeme özelliği
$ git rebase master

Bu, özellik dalının tamamını ana dalın üzerine taşır. Bunu, özgün (özellik) daldaki her bir taahhüt için yepyeni taahhütler oluşturarak proje tarihini yeniden yazarak yapar.

Etkileşimli Rebasing

Bu, komisyonların yeni şubeye taşınırken değiştirilmesini sağlar. Bu, şubenin taahhüt geçmişi üzerinde tam kontrol sağladığı için otomatik yeniden yapılanmadan daha güçlüdür. Genelde bu, bir özellik dalını ana birimde birleştirmeden önce dağınık bir geçmişi temizlemek için kullanılır.

$ git ödeme özelliği
$ git rebase -i master

Bu, taşınacak olan tüm taahhütleri listeleyerek editörü açacaktır.

22d6d7c al Mesaj 1'i tamamla
44e8a9b al Mesaj gönder # 2
79f1d2h seç Mesaj gönder # 3

Bu, rebase yapıldıktan sonra dalın nasıl görüneceğini tam olarak tanımlar. Varlıkları yeniden sipariş ederek, tarihi istediğiniz gibi görünmesini sağlayabilirsiniz. Örneğin, tespit yerine fixup, squash, edit vb. Komutları kullanabilirsiniz.

Hangisini kullanmak

Peki en iyisi nedir? Uzmanlar ne önerir?

Her takım farklı olduğu için birini veya diğerini genellemek ve karar vermek zordur. Ama bir yerden başlamalıyız.

Ekiplerin Git yeniden düzenleme ve birleştirme politikalarını belirlerken bazı soruları göz önünde bulundurmaları gerekir. Çünkü, ortaya çıktığı gibi, bir iş akışı stratejisi diğerinden daha iyi değildir. Takımınıza bağlı.

Kuruluşunuzdaki yeniden yapılandırma ve Git uzmanlığının düzeyini göz önünde bulundurun. Yeniden birleştirmenin basitliğini, izlenebilirlik ve birleştirme geçmişine kıyasla ne derece değer verdiğinizi belirleyin.

Son olarak, birleşme ve yeniden yapılanma kararları açık bir dallanma stratejisi bağlamında değerlendirilmelidir (Dallanma stratejisi hakkında daha fazla bilgi edinmek için bu makaleye bakın). Takımlarınızın organizasyonu etrafında başarılı bir dallanma stratejisi tasarlanmıştır.

Ne öneririm?

Ekip büyüdükçe, gelişim değişikliklerini her zaman bir birleştirme politikasıyla yönetmek veya izlemek zorlaşacaktır. Temiz ve anlaşılır bir işlem geçmişine sahip olmak için, Rebase'i kullanmak makul ve etkilidir.

Aşağıdaki koşulları ve kuralları dikkate alarak, Rebase'den en iyi şekilde yararlanabilirsiniz:

  • Yerel olarak gelişiyorsunuz: Çalışmanızı başkalarıyla paylaşmadıysanız. Bu noktada, geçmişinizi düzenli tutmak için birleştirme yerine yeniden doğmayı tercih etmelisiniz. Eğer kişisel depo deponuz varsa ve diğer geliştiricilerle paylaşılmamışsa, şubenize gönderildikten sonra bile yeniden ödeme yapmanız güvenlidir.
  • Kodunuz incelemeye hazır: Bir çekme isteği oluşturdunuz. Diğerleri çalışmanızı gözden geçiriyor ve yerel inceleme için potansiyel olarak onların çatallarına sokuyor. Bu noktada, işinizi yeniden yapmamalısınız. 'Yeniden işleme' taahhütleri oluşturmalı ve özellik şubenizi güncellemelisiniz. Bu, çekme isteğinde izlenebilirliğe yardımcı olur ve yanlışlıkla tarihin bozulmasını önler.
  • Gözden geçirme yapıldı ve hedef şubeye entegre edilmeye hazır. Tebrikler! Özellik dalınızı silmek üzeresiniz. Diğer geliştiricilerin bu değişikliklerle bu noktadan itibaren bir araya gelmeyeceği göz önüne alındığında, bu sizin tarihinizi dezenfekte etme şansınızdır. Bu noktada, tarihi yeniden yazabilir ve orijinal taahhütleri ve bu sinir bozucu 'ön eleme' ve 'birleştirme' taahhütlerini küçük bir odaklanmış taahhütler kümesine katlayabilirsiniz. Bu taahhütler için açık bir birleştirme oluşturmak isteğe bağlıdır, ancak değeri vardır. Bu özellik ana mezun olduktan sonra kaydeder.

Sonuç

Umarım bu açıklama Git birleştirme ve Git'in yeniden yapılandırılması hakkında bazı görüşler vermiştir. Birleştirme vs rebase stratejisi her zaman tartışılabilir. Ancak belki de bu makale, şüphelerinizi gidermenize yardımcı olacak ve ekibiniz için işe yarayan bir yaklaşım benimsemenize izin verecektir.

Git iş akışları ve Git kavramlarını yazmayı dört gözle bekliyorum. Bir sonraki hakkında yazmamı istediğiniz konular hakkında yorum yapın. Şerefe!

kod = kahve + geliştirici

İşte başka bir faydalı referans

  • Git dallanma stratejisi nasıl benimsenir?

yazılım geliştiriciler için kodlama okulu