Git merge mü rebase mi: farklar, komutlar ve doğru kullanım

Merge ve rebase aynı sorunu nasıl farklı çözer?

İkisi de bir daldaki değişiklikleri başka bir dala taşır. Fark, geçmişin nasıl görüneceğindedir. Merge, dalların geçmişini olduğu gibi korur ve bunları birleştiren yeni bir birleştirme işlemesi (merge commit) üretir. Geçmişte dalın ayrıldığı ve geri döndüğü nokta görünür kalır. Rebase ise kendi dalınızdaki işlemeleri alır, hedef dalın en güncel ucuna taşıyıp yeniden oynatır; sonuçta geçmiş tek çizgi gibi görünür.

Merge geçmişi değiştirmez, rebase değiştirir. Rebase sonrası işlemelerin içeriği aynı olsa da kimlikleri (hash) değişir, çünkü her işleme bir önceki işlemeye bağlıdır. Bu tek ayrıntı, hangisini ne zaman kullanacağınızı belirleyen kuralların kaynağıdır.

Merge nasıl yapılır, geçmişte ne bırakır?

Özellik dalındaki işi ana dala almak için ana dala geçip birleştirirsiniz:

git switch main git merge feature/odeme-ekrani

Dallar ayrışmışsa Git yeni bir birleştirme işlemesi oluşturur. Ayrışma yoksa yalnızca dal işaretçisini ileri taşır (fast-forward). Birleştirme işlemesini her durumda istiyorsanız --no-ff bayrağı kullanılır; bu, özelliğin hangi işlemelerden oluştuğunu ana dalda tek bir grup olarak görmenizi sağlar.

İşlemeleri tek bir işlemede toplamak isterseniz --squash bayrağı vardır; özellik dalının tüm değişikliği tek işleme olarak hazırlanır. Merge'in avantajı güvenli olmasıdır: ortak dallarda kimsenin geçmişini bozmaz. Dezavantajı, çok sayıda dal ve birleştirme işlemesi olan projelerde geçmişin karmaşık bir ağa dönüşmesidir.

Rebase nasıl yapılır?

Özellik dalınız ana daldan geride kaldıysa ve güncel değişiklikleri kendi dalınıza almak istiyorsanız:

git switch feature/odeme-ekrani git rebase main

Git, dalınızdaki işlemeleri geçici olarak kenara alır, dalı main'in ucuna taşır ve işlemelerinizi tek tek yeniden uygular. Çakışma çıkarsa rebase durur; dosyaları düzeltir, git add ile işaretler ve git rebase --continue ile sürdürürsünüz. Vazgeçmek için git rebase --abort dalı başlangıç durumuna döndürür.

Rebase sonrası geçmiş doğrusal olur; ana dala alırken genellikle fast-forward ile birleşir. Yayımlanmış bir dalı rebase ettiyseniz uzak dal ile yerel dal ayrışır ve gönderim için zorlama gerekir: git push --force-with-lease. Bu seçenek, uzak dalda başkası sizin bilmediğiniz bir değişiklik yapmışsa gönderimi reddeder ve düz --force'a göre çok daha güvenlidir.

Interactive rebase ile geçmişi temizlemek

Etkileşimli rebase (git rebase -i main), dalınızdaki işlemeleri bir liste olarak gösterir ve her biri için ne yapılacağını seçtirir:

• pick: işlemeyi olduğu gibi tut
• reword: işleme mesajını değiştir
• squash ve fixup: işlemeyi bir öncekiyle birleştir
• drop: işlemeyi çıkar
• edit: işlemede dur ve içeriği değiştir

Tipik kullanım: gün içinde yazdığınız "düzeltme", "yazım hatası", "tekrar dene" gibi işlemeleri anlamlı birkaç işlemeye indirgemek. Yorum satırı gibi önemsiz değişiklikleri temizleyip incelemecinin okuyacağı geçmişi düzenli hâle getirirsiniz.

Bu yetki yalnızca henüz paylaşılmamış ya da yalnızca sizin çalıştığınız dalda kullanılmalıdır. Başkalarının üzerine kurduğu işlemeleri yeniden yazarsanız onların yerel geçmişi sizinkiyle çelişir ve düzeltmesi zor karışıklıklar çıkar.

Hangisini ne zaman seçmeli? Karar ölçütleri

Genel kural: paylaşılmış dalı rebase etmeyin. Birçok kişinin üzerinde çalıştığı dalda ya da ana dalda geçmiş yeniden yazılmaz. Kendi özellik dalınızı güncel tutmak için rebase uygundur; özelliği ana dala almak için ise ekibin tercihi belirleyicidir.

Ölçüt ve öneri:

• Ortak dal, birden fazla kişi: merge
• Kendi özellik dalını güncel tutmak: rebase
• Geçmişi okunur ve doğrusal tutmak isteyen ekip: rebase ve fast-forward ya da squash
• Özelliğin hangi işlemelerden oluştuğunun korunması gerekiyorsa: --no-ff merge
• Hata ayıklama için işlemelerin ayrıntılı geçmişe ihtiyacı varsa: merge veya düzenlenmiş işleme dizisi

Pull request üzerinden çalışan ekiplerde bu kararı çoğu zaman platformdaki birleştirme seçeneği (merge, squash, rebase) belirler. Hangisinin kullanılacağını ekip standardı olarak yazılı hâle getirmek, her inceleme sırasında aynı tartışmanın tekrarlanmasını önler.

Günlük akışta pull --rebase ve kurtarma

Uzak dalı çekerken Git varsayılan olarak merge yapar ve her çekmede gereksiz birleştirme işlemeleri oluşabilir. git pull --rebase bu durumda yerel işlemelerinizi uzaktaki güncel dalın üzerine taşır ve geçmişi temiz tutar. Bunu varsayılan yapmak için yapılandırmadan pull.rebase seçeneği ayarlanabilir.

Bir rebase ya da merge yanlış gittiyse veri kaybı korkusuna kapılmayın. Git yapılan her dal işaretçisi hareketini reflog'da tutar. git reflog ile işlemin öncesindeki durumu bulup git reset --hard ile o noktaya dönebilirsiniz. Rebase sırasında takıldıysanız git rebase --abort en güvenli çıkıştır. Ayrıca riskli bir rebase öncesinde mevcut dalın üzerine bir yedek dal açmak (git branch yedek) en basit emniyettir.

Sık yapılan hatalar

İlk hata, ortak dalı rebase edip zorla göndermektir: ekip arkadaşlarının yerel geçmişi uzak daldan ayrışır ve herkes çakışma çözmeye başlar. Zorlama gerekiyorsa her zaman --force-with-lease kullanın ve dalın yalnızca size ait olduğundan emin olun.

Diğer hatalar: çakışma çözerken kendi ya da karşı tarafın değişikliğini bilinçsizce seçmek, rebase sırasında çok sayıda işleme olduğu için aynı çakışmayı tekrar tekrar çözmek (önce işlemeleri birleştirmek bunu azaltır), merge işlemesinin mesajını boş bırakmak ve rebase sonrası testleri yeniden çalıştırmamak. Rebase her işlemeyi yeni tabanda yeniden uygular; tek tek işlemeler artık derlenmeyebilir. Birleştirmeden önce derleme ve testlerin geçtiğinden emin olun.

Bu beceri Mindset programlarında nerede çalışılır?

Mindset'in GIT ve GITHUB Uzmanlığı Eğitimi, branch yönetimi ve merge işlemleri ile ileri düzey Git tekniklerini içerir; Git İleri Seviye: Branching, Rebase ve Monorepo eğitimi ise Git nesne modeli, dallanma stratejileri ve birleştirme, geçmiş düzenleme ve sorun teşhisi ile monorepo iş akışlarına odaklanır. İlk eğitim ekip içi iş birliği alışkanlığı kazanmak isteyen geliştiricilere, Git İleri Seviye eğitimi ise geçmiş düzenleme ve ekip standardı belirleyen deneyimli geliştirici ve teknik liderlere uygundur.

Kurumsal yazılım ekipleri için merge ve rebase kararının ekip standardı olarak yazılması ve ortak bir pull request akışına bağlanması bu eğitimlerin doğrudan kullanılabilir çıktısıdır.