Git birleştirme nasıl kullanılır?
Özet: Bir geliştirme şubesini mevcut şubeyle birleştirmek için git birleştirme dev-branch-name kullanın. Bir birleştirmeyle ilgili çakışma uyarıları alırsanız, bundan çıkmak için git birleştirme --abort kullanın veya etkilenen dosyaları düzenleyin ve ardından bunları kesinleştirin.
Git, kararlı sürüm dalının kirlenmesini önlemek için geliştirme akışlarını izole etmek için dalları kullanır. Bir şubedeki işi ana akıma taşımak, şubeleri birleştirmek anlamına gelir. İşte bunu nasıl yapacağınız.
Git'te Birleştirme Nedir?
Git, dallanmayı basit ve hızlı hale getirmek için tasarlandı. Diğer sürüm kontrol sistemlerinin aksine, Git'te dallanma önemsiz bir konudur. Özellikle çok geliştiricili projelerde dallanma, Git'in temel organizasyonel araçlarından biridir.
Dallar, yeni geliştirme çabalarını korumalı alana alır, böylece kod diğer dallardaki, özellikle ana veya ana daldaki kodu etkilemeden değiştirilebilir veya eklenebilir. Bu genellikle kod tabanınızın kararlı sürümünü içerir.
Bu değişiklikleri kararlı kod sürümünüzden izole etmek çok mantıklı. Ancak er ya da geç yeni kod test edilecek, gözden geçirilecek ve ana şubeye gönderilmek üzere onaylanacak. Bu noktada, şubenizi ana şubeyle birleştirmeniz gerekir.
Aslında, şubelerin alt şubeleri olabilir, bu nedenle şubenizi ana şube yerine başka bir şubeyle birleştiriyor olabilirsiniz. Birleştirmelerin her zaman bir dal aldığını ve onu bir hedef dalda birleştirdiğini, o dal ne olursa olsun unutmayın. Master şubenizi başka bir şubeyle birleştirmek isterseniz onu da yapabilirsiniz.
Git'teki çoğu eylem gibi, yerel deponuzda birleştirmeler gerçekleştirir ve bunları uzak deponuza gönderirsiniz.
Git'te Bir Dalı Birleştirmeye Hazırlanma
Yerel Git deposu ve uzak Git deposu olan küçük bir geliştirme projemiz var. “Master” dalından “bugfix14” isimli bir şube oluşturduk ve bir bug'a çözüm üzerinde çalıştık.
Bu çalışma tamamlandı ve kodumuzu test ettik. Her şey beklendiği gibi çalışıyor. Düzeltmemizin yazılımın bir sonraki sürümünün bir parçası olması için bu değişiklikleri ana dala aktarmak istiyoruz.
Birleştirmeyi gerçekleştirmeden önce yapılması gereken küçük bir hazırlık var. Hedef şubenin - bu durumda ana şubenin - ve onunla birleştireceğimiz şubenin güncel olduğundan emin olmamız gerekiyor.
Bunu yapmak için git status komutunu kullanacağız.
git status
- Şubede bugfix14: Bu bizim şu anki şubemiz.
- Şubeniz 'origin/bugfix' ile güncel: Yerel havuzumuzdaki şube, uzak depodaki şubeyle aynı taahhüt geçmişine sahiptir. Bu, aynı oldukları anlamına gelir.
- Taahhüt edilecek bir şey yok Hazırlık alanında taahhüt edilmemiş herhangi bir değişiklik yoktur.
- çalışan ağaç temiz: Çalışma dizininde hazırlanmamış değişiklik yok.
Bunların tümü, şubenin güncel olduğunu ve devam edebileceğimizi gösteriyor. Bunlardan herhangi biri değişikliklerin var olduğunu gösteriyorsa, bunları hazırlamamız, taahhüt etmemiz ve uzaktan kumandaya göndermemiz gerekir. Bu dosyalar üzerinde başka biri çalışmışsa, değişikliklerini uzak depodan çekmemiz gerekebilir.
Birleştireceğimiz şubeyi kontrol etmek, birleştirme işlemini basitleştirir. Ayrıca güncel olduğunu doğrulamamızı da sağlar. Ana şubeye bir göz atalım.
git checkout master
git status
Ana şubenin güncel olduğuna dair aynı onayları alıyoruz.
Birleştirme gerçekleştirme
Birleşmeden önce, taahhütlerimiz şöyle görünür.
bugfix14 şubesi, master şubesinden ayrıldı. bugfix14 dalı oluşturulduktan sonra master dalı için bir taahhüt olmuştur. bugfix14 şubesine birkaç taahhüt verildi.
İki şubemizin güncel olduğundan emin olduk ve ana şubeyi kontrol ettik. bugfix14 dalını master dalıyla birleştirmek için komut verebiliriz.
git merge bugfix14
Birleştirme gerçekleşir. bugfix14 dalı hala mevcuttur, ancak artık o dalda yapılan değişiklikler master dalı ile birleştirilmiştir.
Bu örnekte, birleştirme komutu bir üç yollu birleştirme gerçekleştirir. Yalnızca iki şube var, ancak ilgili üç taahhüt var. Her iki şubenin de başıdırlar ve birleştirme eyleminin kendisini temsil eden üçüncü bir taahhüttür.
Uzak depomuzu güncellemek için git push komutunu kullanabiliriz.
git push
Bazı insanlar yan dalları birleştirdikten sonra silmeyi tercih eder. Diğerleri, onları projenin gerçek geliştirme geçmişinin bir kaydı olarak korumaya özen gösterir.
Şubeyi silmek istiyorsanız, bunu -d (delete) seçeneğiyle git branch komutunu kullanarak yapabilirsiniz.
git branch -d bugfix14
Uzak havuzdaki dalı silmek için şu komutu kullanın:
git push origin --delete bugfix14
Doğrusal bir taahhüt geçmişiniz olacak, ancak bu gerçek tarih olmayacak.
Git'te Hızlı İleri Birleştirme Gerçekleştirme
“Master” şubesine herhangi bir taahhütte bulunmadıysanız, geçmişiniz şöyle görünecektir. Ayrıca, geliştirme dalınızı ana dalın sonuna eklenecek şekilde yeniden temellendirdiyseniz, bu şekilde görünecektir.
Master dalında herhangi bir taahhüt olmadığından bugfix15 dalını birleştirmek için Git'in tek yapması gereken master baş işaretçisini bugfix15 dalının son taahhüdüne yönlendirmek.
Her zamanki git birleştirme komutunu kullanabiliriz:
git merge bugfix15
Bu da bize şu sonucu veriyor.
Hangisi bununla aynı:
Bu sadece bununla aynı:
Git, yapabildiği her fırsatta hızlı ileri birleştirme gerçekleştirecektir. Ana daldaki taahhütler hızlı ileri birleştirmenin mümkün olmadığı anlamına geliyorsa, Git bir üç yollu birleştirme kullanır.
Hızlı ileri birleştirme zorlayamazsınız -sonuçta bu mümkün olmayabilir- ancak bunun hızlı ileri birleştirme olacağını veya hiçbir şey olmayacağını beyan edebilirsiniz. Git'e yapabiliyorsa hızlı ileri birleştirme kullanmasını, yapamıyorsa üç yollu birleştirme yapmamasını söyleyen bir seçenek vardır. Seçenek --ff-only şeklindedir (yalnızca hızlı ileri sarma).
Bu, bugfix15 dalını ana dalla birleştirir, ancak yalnızca hızlı ileri sarma mümkünse.
git merge --ff-only bugfix15
Git şikayet edecek ve mümkün değilse çıkacaktır.
git merge --ff-only bugfix16
Bu durumda, ana dalda taahhütler vardır, bu nedenle hızlı ileri birleştirme mümkün değildir.
Git'te Birleştirme Çakışmaları Nasıl Çözülür?
Her iki dalda da aynı dosyanın aynı bölümleri değiştirilmişse, dallar birleştirilemez. Çakışan düzenlemeleri çözmek için insan etkileşimi gereklidir.
Burada “bugfix17” adlı bir dalda bulunan “rot.c” adlı bir dosyada “master” dalına birleştirmek istediğimiz değişiklikleri yaptık. Ancak “master” dalında da “rot.c” değişmiştir.
git merge bugfix17
Birleştirmeye çalıştığımızda çakışma olduğuna dair bir uyarı alıyoruz. Git, çakışan dosyaları listeler ve bize birleştirmenin başarısız olduğunu söyler. --abort seçeneğini kullanarak tamamen geri adım atabiliriz:
git merge --abort
Ancak birleştirmeleri çözmek göründüğü kadar korkutucu değil. Git bize yardımcı olmak için bazı çalışmalar yaptı. Çakışan dosyalardan birini düzenlersek -bizim durumumuzda yalnızca bir tane var- çakışan kod bölümlerinin bizim için vurgulanmış olduğunu görürüz.
Her çakışma, yedi küçüktür <<<<<< karakteri ve yedi büyüktür >>>>>>> karakteriyle sınırlandırılmıştır. yedi eşittir işareti “=======” aralarında.
- Eşittir işaretlerinin üzerindeki kod, ile birleştirdiğiniz daldandır.
- Eşittir işaretinin altındaki kod, birleştirmeye çalıştığınız dalın kodudur.
Yedi karakterlik kümelerden birini kolayca arayabilir ve dosyanız aracılığıyla bir çatışmadan diğerine geçebilirsiniz. Her çakışma için, hangi düzenleme grubunu tutacağınızı seçmeniz gerekir. Reddettiğiniz kodu ve Git'in eklediği yedi karakterlik satırları düzenlemelisiniz.
Kodu bugfix17 dalından tutacağız. Düzenledikten sonra dosyamız bu şekilde görünüyor.
Şimdi birleştirme işlemine devam edebiliriz. Ancak bunun için merge komutunu değil, commit komutunu kullandığımızı unutmayın.
Dosyayı hazırlayarak ve her zamanki gibi taahhüt ederek değişikliği taahhüt ederiz. Son taahhüdü yapmadan önce durumu kontrol edeceğiz.
git add rot.c
git status
git commit -m "Merged bugfix17"
Birleştirme tamamlandı. Artık bunu uzak depomuza gönderebiliriz.
Her şey Sonunda Birleşir
Sonunda tüm dalların birleştirilmesi gerekir, böylece içlerindeki değişiklikler yetim kalmasın ve unutulmasın.
Şubeleri birleştirmek kolaydır, ancak yoğun, daha büyük ekiplerde çatışmalarla uğraşmak karmaşık hale gelebilir. Çakışmaları çözmek, kodlarının ne işe yaradığını ve değişikliklerini neden yaptıklarını açıklamak için her geliştiriciden girdi gerektirebilir. Hangi düzenlemeleri saklayacağınız konusunda bilinçli bir karar vermeden önce bunu anlamanız gerekir.
Ne yazık ki Git bu konuda yardımcı olamaz.