Git'te rebase mi, merge mi? Ekipte kavga çıkarmadan karar vermek

Rebase temiz bir geçmiş verir ama yanlış yerde kullanılırsa ekip arkadaşınızın işini siler. Merge güvenlidir ama geçmişi karmaşıklaştırır. İkisinin farkını, altın kuralı ve pratikte kullandığım düzeni anlatıyorum.

Taha Bayar 26 Eylül 2026 2 dk okuma

Ana daldaki yeni değişiklikleri kendi dalınıza almanın iki yolu var ve ikisinin de hararetli savunucuları var. Aslında ikisi farklı işler için.

Merge: geçmişi olduğu gibi korur

git switch ozellik
git merge main

İki dalın birleştiği yerde bir birleştirme commit'i oluşur. Hiçbir commit değişmez. Güvenlidir, ama çok sayıda birleştirme commit'i geçmişi okumayı zorlaştırır.

Rebase: commit'lerinizi yeniden yazar

git switch ozellik
git rebase main

Sizin commit'leriniz, ana dalın en ucuna taşınmış gibi yeniden oluşturulur. Geçmiş düz bir çizgi olur. Ama commit'lerin kimliği (hash) değişir.

Altın kural

Başkalarının da üzerinde çalıştığı, paylaşılmış bir dalı rebase etmeyin. Commit'ler değiştiği için ekip arkadaşınızın elindeki geçmişle sizinki uyuşmaz ve zorla gönderim (force push) onların işini ezebilir.

Kendi dalınızı yine de zorla göndermeniz gerekirse --force yerine şunu kullanın:

git push --force-with-lease

Bu, uzak dalda sizin görmediğiniz bir değişiklik varsa gönderimi reddeder.

Pratikte kullandığım düzen

git config --global pull.rebase true: git pull her seferinde gereksiz birleştirme commit'i üretmez.
Yalnızca bana ait özellik dalını, ana dala göndermeden önce rebase ederim.
Dağınık commit'leri (düzeltme, yine düzeltme) göndermeden önce etkileşimli rebase ile toparlarım.
Ana dala birleştirmeyi pull request üzerinden yaparım; ekip "squash" mı "merge" mi kullanacağına bir kez karar verir ve herkes ona uyar.

Bir şey ters giderse

git reflog

Rebase sonrası "commit'lerim kayboldu" panikleri için kurtarıcı. Git, dalın son haftalarda gösterdiği her noktayı burada tutar; eski hâle git reset --hard <kayıt> ile dönebilirsiniz.