Git rebase: Bilmeniz Gereken Her Şey

Git rebase komutu, iki kaynak kodu dalını bir dalda birleştirir. Git merge komutu da bunu yapar. rebase ne işe yaradığını, nasıl kullanıldığını ve bunun yerine merge ne zaman kullanılacağını açıklıyoruz.

Git Patlaması

Diğer sürüm kontrol sistemlerinden ve onların yavaş güncellemelerinden ve taahhütlerinden bıkan Linux çekirdeği şöhreti olan Linus Torvalds, 2005'te kendi sürümünü yazmak için bir ay ayırdı. Adını Git koydu.

GitHub, GitLab ve BitBucket gibi siteler simbiyotik olarak Git'i destekledi ve ondan yararlandı. Bugün Git, sürüm kontrol sistemi olarak Git'i kullanan 2022 anketinde 71 bin katılımcının yüzde 98'i ile küresel olarak kullanılıyor.

Git'in ana tasarım kararlarından biri hızdı. Özellikle şubelerle çalışmanın olabildiğince hızlı olması gerekiyordu. Şubeler, sürüm kontrol sistemlerinin temel bir parçasıdır. Bir proje deposunun bir ana veya ana dalı olacaktır. Burası, projenin kod tabanının oturduğu yerdir. Yeni özellikler gibi geliştirmeler, ayrılmış yan dallarda gerçekleşir. Bu, şubelerde yapılan işlerin ana şubeyi karıştırmasını engeller ve kod tabanının farklı bölümlerinde eş zamanlı geliştirme yapılmasına izin verir.

İLGİLİ Ekibiniz İçin Doğru Git İş Akışı ve Dallanma Modelini Nasıl Seçersiniz?

Yan dallardaki geliştirmeler tamamlandıktan sonra geliştirme dalının ana dal ile birleştirilmesi ile değişiklikler ana dalda aktarılır. Diğer sürüm kontrol sistemlerinde şubelerle çalışmak zordu ve hesaplama açısından pahalıydı. Git'te şubelerle çalışmak çok hızlı ve çok hafiftir. Bir zamanlar diğer sistemlerde sıkıcı ve sıklıkla kaçınılan bir egzersiz, Git'te önemsiz hale geldi.

Git rebase komutu, değişiklikleri bir şubeden başka bir şubeye aktarmanın başka bir yoludur. merge ve yeniden rebase komutlarının benzer amaçları vardır, ancak amaçlarına farklı şekillerde ulaşırlar ve biraz farklı sonuçlar verirler.

Git birleştirme nedir?

Peki Git merge komutu ne için? Diyelim ki yeni bir özellik üzerinde çalışmak için dev-branch adlı bir dal oluşturdunuz.

Birkaç işlem yaparsınız ve yeni özelliğinizi test edersiniz. Hepsi iyi çalışıyor. Şimdi yeni özelliğinizi master şubeye göndermek istiyorsunuz. Bir başkasını onunla birleştirmek için master dalda olmalısınız.

Birleştirmeden önce açıkça kontrol ederek master dalda olduğumuzdan emin olabiliriz.

 git ödeme ustası

Artık Git'e dev-branch master dal olan geçerli dalla birleştirmesini söyleyebiliriz.

 git dev şubesini birleştirme 

Bizim için merge tamamlandı. master dalı kontrol edip derlerseniz, içinde yeni geliştirilen özelliğe sahip olacaktır. Git'in gerçekte gerçekleştirdiği şey, üç yollu birleştirmedir. master ve dev-branch şubelerindeki en son commit'leri ve dev- dev-branch oluşturulmadan hemen önce master dalındaki commit'leri karşılaştırır. Daha sonra master dalda bir taahhüt gerçekleştirir.

Birleştirmeler, hiçbir şeyi silmedikleri ve Git geçmişini değiştirmedikleri için tahribatsız kabul edilir. Geliştirme dev-branch hala var ve önceki taahhütlerin hiçbiri değiştirilmedi. Üç yollu birleştirmenin sonuçlarını yakalayan yeni bir taahhüt oluşturulur.

Birleştirmeden sonra Git depomuz, alternatif bir hattın dallanarak ana zaman çizelgesine geri döndüğü bir zaman çizelgesi gibi görünür.

dev-branch şubesi, master şubeye dahil edildi.

Bir projede çok sayıda şubeniz varsa, projenin geçmişi kafa karıştırıcı olabilir. Bir projenin çok sayıda katılımcısı varsa, bu genellikle geçerlidir. Geliştirme çabası birçok farklı yola ayrıldığından, geliştirme geçmişi doğrusal değildir. Şubelerin kendi şubeleri varsa, taahhüt geçmişini çözmek daha da zor hale gelir.

İLGİLİ Git Dalları Nasıl Çalışır?

master dalda kaydedilmemiş değişiklikleriniz varsa, herhangi bir şeyi birleştirmeden önce bu değişikliklerle bir şeyler yapmanız gerekeceğini unutmayın. Yeni bir şube oluşturabilir ve değişiklikleri orada yapabilir ve ardından birleştirmeyi yapabilirsiniz. Daha sonra geçici şubenizi tekrar ana şubede birleştirmeniz gerekir.

Bu işe yarar, ancak Git'in yeni dallar oluşturmak zorunda kalmadan aynı şeyi başaran bir komutu vardır. stash komutu, kaydedilmemiş değişikliklerinizi sizin için depolar ve bunları stash pop ile geri çağırmanıza izin verir.

Onları şu şekilde kullanırsın:

 saklamak

git dev şubesini birleştirme

zula pop

Sonuç, kaydedilmemiş değişikliklerinizin geri yüklendiği birleştirilmiş bir daldır.

Git rebase nedir?

Git rebase komutu, amaçlarına tamamen farklı bir şekilde ulaşır. Yeniden temellendireceğiniz daldaki tüm taahhütleri alır ve bunları yeniden temellendireceğiniz dalın sonuna kadar yeniden yürütür.

Önceki örneğimizi ele alırsak, herhangi bir işlem gerçekleştirmeden önce Git depomuz bu şekilde görünür. dev-branch branch adında bir şubemiz var ve bu değişiklikleri master şubeye taşımak istiyoruz.

Yeniden rebase sonra, tek, tamamen doğrusal bir değişiklik zaman çizelgesi gibi görünür.

dev-branch kaldırıldı ve dev-branch içindeki commit'ler ana şubeye eklendi. Nihai sonuç, dev-branch taahhütler aslında ilk etapta doğrudan master şubeye taahhüt edilmiş gibi aynıdır. Taahhütler sadece master şubeye iliştirilmez, "tekrar oynatılır" ve taze eklenir.

Bu nedenle rebase komutunun yıkıcı olduğu kabul edilir. Yeniden temellendirilen dal artık ayrı bir dal olarak mevcut değildir ve projenizin Git geçmişi yeniden yazılmıştır. Daha sonraki bir noktada, dev-branch başlangıçta hangi taahhütlerin verildiğini belirleyemezsiniz.

Ancak, size basitleştirilmiş, doğrusal bir tarih bırakıyor. Düzinelerce hatta yüzlerce dal ve birleştirme içeren bir havuzla karşılaştırıldığında, Git günlüğünü okumak veya deponun grafiğine bakmak için grafiksel bir git GUI kullanmak, yeniden temellendirilmiş bir havuzu anlamak çok kolaydır.

Başka Bir Dala Nasıl Yeniden Başlanır

Bir git rebase örneği deneyelim. new-feature adında bir dalı olan bir projemiz var. Bu dalı bu şekilde master dala yeniden rebase .

İlk olarak, master dalda göze çarpan değişiklik olup olmadığını kontrol ediyoruz.

 git durumu

new-feature şubesini kontrol ediyoruz.

 git checkout yeni özelliği

Git'e mevcut dalı ana dala yeniden rebase söylüyoruz.

 git rebase ustası

Hala iki şubemiz olduğunu görebiliyoruz.

 git şubesi

master şubeye geri dönüyoruz

 git ödeme ustası

Yeni özellik dalını, bizim durumumuzda master dal olan mevcut dalla birleştiriyoruz.

 git birleştirme yeni özelliği 

İlginç bir şekilde, son birleşmeden sonra hala iki şubemiz var.

Fark şu ki, artık new-feature dalının başı ve master dalın başı aynı taahhüdü işaret edecek şekilde ayarlanmış ve Git geçmişi, eskiden ayrı bir new-feature dalı olduğunu göstermiyor. şube etiketi.

Git Rebase ve Birleştirme: Hangisini Kullanmalısınız?

Bu bir rebase vs merge durumu değil. İkisi de güçlü komutlardır ve muhtemelen ikisini de kullanacaksınız. Bununla birlikte, rebase gerçekten o kadar iyi çalışmadığı kullanım durumları var. merge kullanılarak yapılan hatalardan kaynaklanan hataların ayıklanması hoş değildir, ancak yeniden yapılanmanın neden olduğu hataların rebase cehennem gibidir.

Depo kullanan tek geliştirici sizseniz, rebase ile feci bir şey yapma şansınız daha düşüktür. Örneğin, yine de yanlış yönde yeniden temel alabilir ve ana rebase new-feature rebase yeniden temellendirebilirsiniz. master şubenizi geri almak için, bu sefer new-feature rebase master şubenize yeniden temel atmanız gerekir. Bu, tuhaf görünen bir geçmişe sahip olsa da, master dalınızı geri yükler.

rebase , başkalarının çalışabileceği paylaşılan şubelerde kullanmayın. Deponuzdaki değişiklikleriniz, yeniden oluşturulmuş kodunuzu uzak deponuza gönderdiğinizde birçok insan için sorun yaratacaktır.

Projenizde birden çok katkıda bulunan varsa, yapılacak en güvenli şey rebase genel şubelerde değil, yalnızca yerel deponuzda kullanmaktır. Aynı şekilde, çekme istekleri kod incelemelerinizin bir parçasını oluşturuyorsa, rebase kullanmayın. Ya da en azından, çekme talebini oluşturduktan sonra rebase kullanmayın. Diğer geliştiriciler büyük olasılıkla taahhütlerinize bakıyor olacaklar, bu da bu değişikliklerin master dalda olmasalar bile genel bir dalda olduğu anlamına gelir.

Tehlike şu ki, zaten uzak bir rebase aktarılmış olan taahhütleri yeniden temellendireceksiniz ve diğer geliştiriciler zaten bu taahhütlere dayalı çalışmalar yapmış olabilir. Yerel rebase , mevcut taahhütleri ortadan kaldıracaktır. Bu değişiklikleri depoya aktarırsanız, popüler olmayacaksınız.

İLİŞKİLİ Git İşlemlerini Düzeltme, Düzenleme veya Geri Alma (Git Geçmişini Değiştirme)

Diğer katkıda bulunanlar, çalışmalarını depoya geri göndermek için karmaşık bir merge işleminden geçmek zorunda kalacaklar. Daha sonra değişikliklerini yerel deponuza geri çekerseniz, yinelenen değişiklikler karmaşasını çözmekle karşı karşıya kalırsınız.

Yeniden Temellendirmek mi, Yeniden Temellendirmemek mi?

Rebase , projenizde yasaklanmış olabilir. Yerel, kültürel itirazlar olabilir. Bazı projeler veya kuruluşlar, yeniden yapılanmayı bir tür sapkınlık ve bir saygısızlık rebase olarak görüyor. Bazı insanlar Git geçmişinin, olanların dokunulmaz, kalıcı bir kaydı olması gerektiğine inanıyor. Yani, rebase masanın dışında olabilir.

Ancak yerel olarak, özel şubelerde kullanıldığında, rebase yararlı bir araçtır.

Yeniden temellendirdikten sonra itin ve tek geliştirici olduğunuz şubelerle sınırlandırın. Veya en azından, tüm geliştirmenin durduğu ve başka hiç kimsenin şubenizin taahhütlerinden başka bir işe dayanmadığı yer.

Bunu yapın ve herhangi bir sorundan kaçınacaksınız.

İLGİLİ: Git Sürümünüzü Kontrol Etme ve Güncelleme