Git Rebase mi Git Merge mü? Tertemiz Bir Git Commit Geçmişi İçin Doğru Yöntem Rehberi
Takım çalışmasında dalları birleştirirken yaşanan commit kaosu: Git Merge vs Git Rebase. Commit geçmişini düz bir çizgide tutmanın sırrı, Rebase'in tehlikeleri, altın kural ve ne zaman hangisinin kullanılacağı.
Git ile çalışan hemen her yazılımcının GitHub\'da veya GitLab\'da karşılaştığı trajikomik bir manzara vardır: Projenin 'Network / Graph' geçmişine bir bakarsınız; birbirine girmiş onlarca renkli çizgi, tren rayları gibi dolanmış dallar ve yüzlerce gereksiz 'Merge branch main into feature' commit\'i! Projede 3 ay önce hangi değişikliğin neden yapıldığını bulmak imkansız hale gelmiştir. İşte bu commit kirliliğini engellemek ve geçmişi jilet gibi düz bir çizgide tutmak isteyen geliştiricilerin tartıştığı en büyük iki yöntem: git merge ve git rebase.
Git Merge Nasıl Çalışır?:
Klasik ve en güvenli yöntem git merge komutudur. Diyelim ki main dalından ayrılıp ozellik adında bir branch açtınız ve kod yazdınız. Bu sırada ana daldaki ekip arkadaşlarınız da main\'e yeni commit\'ler attı. Siz git merge main dediğinizde Git; iki dalın geçmişini birleştiren yepyeni bir 'Merge Commit\'i oluşturur.
Avantajı: Kesinlikle tarihi değiştirmez; kimin ne zaman ne yaptığını olduğu gibi korur ve çatışmaları (conflict) tek bir noktada çözersiniz.
Dezavantajı: Her birleştirmede anlamsız bir 'Merge commit\'i geçmişe eklenir ve dallar arttıkça commit geçmişi okunamaz bir örümcek ağına dönüşür.
Git Rebase Nedir ve Nasıl Çalışır? (Zamanı Yeniden Yazmak):
'Rebase' kelimesi tam olarak 'Temeli Yeniden Belirlemek' anlamına gelir. git rebase main dediğinizde Git sihirli bir işlem yapar:
1. Sizin ozellik dalında attığınız yeni commit\'leri geçici bir kenara alır.
2. Sizin dalınızı alır ve sanki main dalındaki en son commit\'ten henüz 1 saniye önce ayrılmışsınız gibi dalın başlangıç temelini (base) en uca taşır.
3. Ardından kenara aldığı commit\'lerinizi sırayla bu yeni temelin ucuna tek tek yeniden uygular (Re-apply)!
Sonuç: Ortada hiçbir 'Merge commit\'i kalmaz. Proje geçmişi sanki herkes sırayla tek bir düz hat üzerinde çalışmış gibi tertemiz, doğrusal (linear) bir çizgi haline gelir!
Rebase'in Altın Kuralı: 'Public Branch'leri Asla Rebase Etme!':
Rebase muazzam bir temizlik sunar ama çok büyük bir tehlikesi vardır: Rebase, commit\'lerin SHA-1 kimliklerini (hash) değiştirir; yani Git tarihini yeniden yazar! Bu yüzden Git dünyasında yazılı olmayan bir altın kural vardır: 'Herkese açık (Public / Main) dalları ASLA rebase etme!'. Eğer arkadaşlarınızın da kod çektiği main dalında rebase yaparsanız, herkesin commit geçmişi bozulur ve ekip arkadaşlarınızın bilgisayarlarında devasa çakışmalar patlak verir. Rebase sadece ve sadece sizin kendi yerel (local) özellik dalınızda yapılmalıdır.
Pratik Tavsiye: Hangi Durumda Hangisi Kullanılmalı?:
- Git Rebase Kullanın: Kendi özellik dalınızda (feature branch) çalışırken ana daldaki (main) yenilikleri kendi dalınıza çekmek istediğinizde (git pull --rebase origin main). Ayrıca Pull Request (PR) açmadan önce commit geçmişinizi temizlemek ve gereksiz 'ufak düzeltme', 'wip' commit\'lerini birleştirmek (Squash) istediğinizde.
- Git Merge Kullanın: Özellik dalınız bittiğinde ve artık ana dala (main) kalıcı olarak katıldığında (git merge --no-ff feature). Bu sayede o büyük özelliğin ne zaman sisteme girdiğini gösteren anlamlı tek bir birleşme noktası tarihte kayıtlı kalır.
Özet: Git Rebase bir heykeltıraş gibi commit geçmişinizi temiz, düzenli ve profesyonel kılmanın aracıdır. Kurallara dikkat ederek kendi yerel dalınızda Rebase, ana birleşmelerde ise Merge kullandığınızda GitHub reponuz dünya standartlarında bir açık kaynak projesi gibi pırıl pırıl parlayacaktır.