Özellik dalınız main‘in gerisinde kaldı ve yeni işlere ihtiyacınız var. Git merge vs rebase, bunu elde etmenin iki yolu arasındaki seçimdir ve ikisi de doğrudur. Fark, sonrasında geçmişin nasıl göründüğündedir.

Küçük bir depo oluşturduk, iki komutu da çalıştırdık ve gerçek çıktıyı aşağıya yapıştırdık; böylece sonucu hayal etmek yerine karşılaştırabilirsiniz. Git’e yeni misiniz? Yeni başlayanlar için Git eğitimimizle (İngilizce) başlayın.

git merge ve git rebase ne yapar

git merge, iki dalın uçlarını alıp birleştirir. İkisinde de yeni commit varsa Git iki ebeveynli bir birleştirme commit’i oluşturur. Var olan hiçbir şey değişmez.

git rebase, yalnızca sizin dalınıza ait commit’leri alıp kenara koyar, dalınızı diğer dalın ucuna taşır ve ardından commit’lerinizi tek tek yeniden oynatır. Yeniden oynatılan commit’ler, değişiklikleri aynı olsa da yeni hash’lere sahip yeni commit’lerdir.

Uygulamada git merge

Başlangıç noktamız: main‘de A commit’i, feature‘da iki commit (F1, F2) ve sonradan main‘e eklenen bir commit daha (M1). Şimdi main‘i feature‘a merge ediyoruz.

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

Grafik gerçek hikâyeyi gösterir: birleştirilen iki iş hattı. Orijinal F1 ve F2 commit’leri hash’lerini korur. Bedeli fazladan bir birleştirme commit’idir ve yoğun bir projede grafik ağa dönüşür.

Uygulamada git rebase

Aynı başlangıç noktası, ama bu kez feature‘ı main‘in üzerine rebase ediyoruz.

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

Geçmiş, işe M1’den sonra başlamışsınız gibi tek bir düz çizgidir. Hash’lere bakın: F1 5a71e3c idi, şimdi bf9149e; F2 082cc6a‘dan 1ff474b‘ye değişti. Git onları yeniden yazdı ve rebase’in dikkat istemesinin nedeni budur.

Merge ve rebase yan yana

Rebase’in altın kuralı

Kendi deponuzun dışında var olan commit’leri rebase etmeyin. Rebase’ten sonra dalınız sunucudaki kopyayla uyuşmaz, bu yüzden göndermek zorlama gerektirir. Bir meslektaşınız eski commit’ler üzerine iş kurduysa onun geçmişi artık sizinkiyle çelişir ve bunu düzeltmek zahmetlidir.

Özel özellik dalınızı rebase etmek sorun değildir. main‘i veya başkalarının kullandığı herhangi bir dalı rebase etmek öyle değildir.

Güvenli bir ekip iş akışı

Bu rutin kimseyi şaşırtmadan geçmişi temiz tutar. Çoğu ekip CI hattından önce bunu kullanır; örneğin GitHub Actions CI/CD rehberimizdeki (İngilizce) hat gibi.

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease, son fetch’inizden beri biri sunucudaki dala push yaptıysa üzerine yazmayı reddeder; düz --force ise bunu sessizce yok ederdi. Pull request onaylandığında main‘e merge edin.

Kötü bir rebase nasıl geri alınır

Rebase yıkıcı görünür ama eski commit’ler bir süre Git’in reflog‘unda kalır, böylece geri dönebilirsiniz.

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

Riskli bir rebase’ten önce git branch backup ile yedek dal oluşturun; kurtarma tek komuta iner. Konteynerlerde veritabanı veya araç mı çalıştırıyorsunuz? Yeni başlayanlar için Docker eğitimimize (İngilizce) bakın.

Son sözler

Merge gerçeği korur, rebase onu derli toplu tutar. Kendi dalınızı tazelemek için rebase, teslim etmek için merge kullanın ve başkalarının bağlı olduğu geçmişi asla yeniden yazmayın.

Sık sorulan sorular

Öğrenmeye devam edin (İngilizce makaleler)