Git rebase komutu, iki kaynak kodu dalını bir dalda birleştirir. Git merge komut bunu da yapar. neyi açıklıyoruz rebase ne işe yarar, nasıl kullanılır ve ne zaman kullanılır merge yerine.
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.
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. bu merge ve rebase komutların benzer hedefleri vardır, ancak amaçlarına farklı şekillerde ulaşırlar ve biraz farklı sonuçlar verirler.
Git birleştirme nedir?
Git nedir peki merge için komut? Diyelim ki adında bir şube oluşturdunuz. dev-branch Yeni bir özellik üzerinde çalışmak için.
Birkaç işlem yaparsınız ve yeni özelliğinizi test edersiniz. Hepsi iyi çalışıyor. Şimdi yeni özelliğinizi şuraya göndermek istiyorsunuz: master dal. içinde olmalısın master ona bir başka birleştirmek için dal.
içinde olduğumuzdan emin olabiliriz master şubeyi birleştirmeden önce açıkça kontrol ederek.
git checkout master
Artık Git’e şunları birleştirmesini söyleyebiliriz: dev-branch geçerli şubeye, yani master dal.
git merge dev-branch
Bizim merge bizim için tamamlandı. Eğer ödeme master dallandırın ve derleyin, içinde yeni geliştirilen özelliğe sahip olacaktır. Git’in gerçekte gerçekleştirdiği şey, üç yollu birleştirmedir. içindeki en son taahhütleri karşılaştırır. master ve dev-branch şubeler ve taahhüt master şubeden hemen önce dev-branch yaratıldı. Daha sonra üzerinde bir taahhüt gerçekleştirir master dal.
Birleştirmeler, hiçbir şeyi silmedikleri ve Git geçmişini değiştirmedikleri için tahribatsız kabul edilir. bu 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.
bu dev-branch şube bünyesine katılmıştır. master dal.
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.
Kaydedilmemiş değişiklikleriniz varsa, master şubede herhangi bir şeyi birleştirmeden önce bu değişikliklerle ilgili bir şeyler yapmanız gerekecek. 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. bu stash komutu, taahhüt edilmemiş değişikliklerinizi sizin için saklar ve bunları stash pop .
Onları şu şekilde kullanırsın:
stash git merge dev-branch stash pop
Sonuç, kaydedilmemiş değişikliklerinizin geri yüklendiği birleştirilmiş bir daldır.
Git rebase nedir?
Git rebase komuta, 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. adında bir şubemiz var. dev-branch ve bu değişiklikleri şuraya taşımak istiyoruz: master dal.
Sonra rebase tek, tamamen doğrusal bir değişiklik zaman çizelgesi gibi görünüyor.
bu dev-branch kaldırıldı ve içindeki taahhütler dev-branch master şubesine eklendi. Nihai sonuç, içindeki taahhütlerle aynıdır. dev-branch aslında doğrudan taahhüt edilmişti master öncelikle şube. Taahhütler sadece master şube, “tekrar oynatılır” ve taze eklenir.
Bu yüzden rebase komut yıkıcı 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. Başlangıçta hangi taahhütlerin yapıldığını daha sonraki bir noktada belirleyemezsiniz. dev-branch.
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
hadi bir deneyelim git rebase örnek. adlı bir şubeyle bir projemiz var. new-feature. Evlenmek rebase o dal üzerine master şube böyle.
İlk olarak, master şubenin önemli bir değişikliği yok.
git status
kontrol ediyoruz new-feature dal.
git checkout new-feature
Git’e söyleyelim rebase mevcut şubeyi ana şubeye aktarın.
git rebase master
Hala iki şubemiz olduğunu görebiliyoruz.
git branch
geri değiş tokuş yapıyoruz master dal
git checkout master
Yeni özellik şubesini mevcut şubeyle birleştiriyoruz, bu bizim durumumuzda master dal.
git merge new-feature
İlginç bir şekilde, son birleşmeden sonra hala iki şubemiz var.
Fark şu ki, şimdi başı new-feature şube ve başkanı master şube aynı taahhüdü gösterecek şekilde ayarlanmıştır ve Git geçmişi, eskiden ayrı bir şube olduğunu göstermez. new-feature şube, şube etiketi dışında.
Git Rebase ve Birleştirme: Hangisini Kullanmalısınız?
bu bir durum değil rebase vs. merge. İkisi de güçlü komutlardır ve muhtemelen ikisini de kullanacaksınız. Bununla birlikte, kullanım durumları vardır ki burada rebase gerçekten o kadar iyi çalışmıyor. Kullanarak hatalardan kaynaklanan hataları ayıklama merge hoş değil, ancak neden olduğu hataları ayıklamak rebase cehennem gibi.
Depo kullanan tek geliştirici sizseniz, bununla bir şeyler yapma şansınız daha düşüktür. rebase bu felaket. hala yapabilirsin rebase örneğin yanlış yönde ve rebase ana şubeniz new-feature dal. senin almak için master geri dal, ihtiyacın olacak rebase yine bu sefer senden new-feature şube senin master dal. Bu senin master şube, garip görünen bir geçmişe sahip olsa da.
kullanma rebase başkalarının çalışabileceği ortak şubelerde. 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 yalnızca rebase senin üzerinde yerel depo ve kamu şubelerinde değil. Aynı şekilde, çekme istekleri kod incelemelerinizin bir parçasını oluşturuyorsa, kullanmayın. rebase. Veya en azından kullanmayın rebase çekme talebini oluşturduktan sonra. Diğer geliştiriciler büyük olasılıkla taahhütlerinize bakıyor olacaklar, bu da bu değişikliklerin genel bir dalda olduğu anlamına gelir. master dal.
Tehlike şu ki yapacaksın rebase zaten uzak bir depoya aktarılmış olan taahhütler ve diğer geliştiriciler zaten bu taahhütlere dayalı işlere sahip olabilir. yerel rebase bu mevcut taahhütleri ortadan kaldıracak. Bu değişiklikleri depoya aktarırsanız, popüler olmayacaksınız.
Diğer katkıda bulunanlar karmaşık bir süreçten geçmek zorunda kalacak merge çalışmalarını depoya geri göndermek için. 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, rebase bir tür sapkınlık ve bir saygısızlık eylemi olarak. 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ılır, rebase kullanışlı bir araçtır.
İtmek sonrasında yeniden temellendirdiniz ve tek geliştirici olduğunuz şubelerle sınırlandırdınız. 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.
İLİŞKİLİ: Git Sürümünüzü Kontrol Etme ve Güncelleme
