Rebase: nedir, Merge'den nasıl farklıdır ve çalışma prensibi

Yazar: IT Sectr Yayınlanma: 2026-05-10 Okuma süresi: 10 dk

Rebase, bir dizi commit'i yeni bir temel commit'e taşıyan ve dal geçmişini yeniden yazan bir Git işlemidir. Merge'in aksine, Rebase bir birleştirme commit'i oluşturmaz, commit'leri hedef dalın mevcut durumu üzerine yeniden uygular. git-scm.com, 2026'ya göre, temiz bir doğrusal commit geçmişi sağlamak için Git projelerinin %58'inde rebase kullanılır.

Anahtar Noktalar

  • Rebase commit'leri yeni bir tabana taşır, dal geçmişini yeniden yazar
  • Doğrusal geçmiş rebase'in ana avantajıdır: git log dallanmalar olmadan okunur
  • Herkese açık dallar için değil — rebase commit'leri yeniden yazar, iş arkadaşlarının geçmişini bozar
  • Etkileşimli rebase commit'leri birleştirmeye, yeniden adlandırmaya ve silmeye olanak tanır
  • Altın kural: başkasının zaten gönderdiği bir dalı asla rebase etmeyin

Rebase Nedir?

Rebase (yeniden temellendirme), mevcut daldan commit'leri yeni bir temel noktasına taşıyan bir Git işlemidir. Bir birleştirme commit'i oluşturmak yerine, rebase kaynak daldaki her commit'i alır ve yeni temel üzerine tek tek uygular. Sonuç, dallanmalar olmadan doğrusal bir commit dizisidir.

Rebase adı “re-base” (tabanı değiştirme) kelimesinden gelir. Merge iki dalı tek bir noktada birleştirirken, rebase tüm dalınızı yeni bir konuma taşıyarak geliştirmeye hedef dalın mevcut durumundan başlamışsınız gibi görünmesini sağlar. Bu, mükemmel sıralı bir çalışma yanılsaması yaratır.

Atlassian, 2025'e göre, özellik dalları için rebase kullanan ekipler, yalnızca merge kullanan ekiplere kıyasla commit geçmişini analiz etmekte %30 daha az zaman harcar. Doğrusal geçmiş, git blame, bisect ve git log --oneline ile log görüntülemeyi basitleştirir.

Merge'den Temel Fark

Merge iki ebeveynli bir commit oluşturarak dalları birleştirir. Rebase geçmişi yeniden yazar: değişiklikleri orijinalleriyle aynı olsa da, yeni hash'lerle yeni commit'ler oluşturulur. Bu, rebase'in commit'lerin SHA tanımlayıcılarını değiştirdiği anlamına gelir ve bu, herkese açık dallar için kritiktir.

Rebase Nasıl Çalışır

Rebase mekanizması dört adımdan oluşur: Git, mevcut dal ile hedef dalın ortak atasını (birleştirme tabanı) belirler, ardından mevcut dalın her commit'ini sırayla hedef dal üzerine uygular. Herhangi bir adımda çakışma oluşursa, rebase durur ve çözüm bekler.

bash
# Başlangıç durumu: feature dalı develop'dan 3 commit geride
git checkout feature/new-login
git rebase develop

# Git, feature'dan 3 commit alır ve develop üzerine uygular
# Çakışma yoksa — rebase otomatik olarak tamamlanır
# Varsa — Git çakışan commit'te durur

Rebase'den sonra, özellik dalı, develop'ın tüm commit'lerini ve develop'ın devamı olarak görünen kendi commit'lerini içerir. Bu, bir birleştirme commit'i oluşturmadan fast-forward ile develop'a birleştirmeye olanak tanır.

Adım Adım Süreç

Ayrıntılı bir örnek ele alalım: bir geliştirici develop'dan bir özellik dalı oluşturdu, iki commit yaptı, bu sırada diğer geliştiriciler develop'a üç commit ekledi. Rebase, iki özellik commit'ini yeni bir konuma taşıyacak ve yeni SHA'larla kopyalarını oluşturacaktır.

bash
# 1. Bir feature dalı oluşturun
git checkout -b feature/payment-refactor develop

# 2. feature'da commit yapın
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. develop'ı güncelleyin (iş arkadaşlarının çalışması)
git checkout develop
git pull

# 4. feature'ı yeni develop üzerine rebase edin
git checkout feature/payment-refactor
git rebase develop

# 5. Artık feature fast-forward ile birleştirilebilir
git checkout develop
git merge feature/payment-refactor

4. adımda bir çakışma oluşursa, Git sorunlu commit'te durur. Geliştirici çakışmayı çözer, git add çalıştırır ve git rebase --continue komutunu verir. Bir commit'i atlamak için — git rebase --skip, tüm rebase'i iptal etmek için — git rebase --abort.

Boş Commit'lerin Otomatik Atlanması

--empty bayrağı, boş commit'lerde (bir commit'in tüm değişikliklerinin zaten hedef dalda bulunduğu durumlar) rebase davranışını kontrol eder. Varsayılan olarak, rebase durur ve karar ister. --empty=drop ile Git, durmadan bu tür commit'leri otomatik olarak atlar ve çok sayıda commit ile toplu yeniden temellendirmeyi hızlandırır.

Etkileşimli Rebase

Etkileşimli rebase (git rebase -i), commit geçmişini düzenlemek için güçlü bir araçtır. Commit'lerin ve anahtar komutların (pick (sakla), reword (mesajı değiştir), edit (içeriği değiştir), squash (öncekiyle birleştir), fixup (mesajsız birleştir), drop (sil)) listesini içeren bir düzenleyici açar.

bash
# Son 4 commit'in etkileşimli rebase'i
git rebase -i HEAD~4

# Düzenleyici bir rebase planı ile açılacak:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Şu şekilde değiştir:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Sonuç: üç commit (giriş ekranı, doğrulama, düzen) tek bir commit'te sıkıştırılır ve yorumların bulunduğu commit silinir. Bu, taslaklar ve düzeltmeler olmadan kod incelemesi için temiz bir geçmiş sunulmasını sağlar. Etkileşimli rebase, bir Pull Request'ten önce özellik dalını hazırlamak için standart bir araçtır.

Rebase vs Merge: Karşılaştırma

Rebase ve Merge aynı sorunu — değişiklikleri entegre etme — ancak temelde farklı şekillerde çözer. Aralarındaki seçim, git log'da ne tür bir geçmiş görmek istediğinize ve dalınızla başka kimlerin çalıştığına bağlıdır.

KriterMergeRebase
GeçmişDallanmayı korurDoğrusal, dalsız
Birleştirme commit'iOluşturulur (ff hariç)Oluşturulmaz
Commit SHADeğişmezYenileri oluşturulur
GüvenlikHerkese açık dallar için güvenliTehlikeli — geçmişi yeniden yazar
Log okunabilirliğiDallanma grafiğiDüz çizgi
git bisectKullanışlı — birleştirme noktası görünürKullanışlı — doğrusal dizi

Pratik kural: ortak dallara (develop, main) entegrasyon için merge kullanın ve kişisel özellik dallarını güncellemek için rebase kullanın. Birçok ekip ikisini birleştirir: özelliği develop üzerine rebase, ardından develop'a --no-ff merge.

git bisect Üzerindeki Etkisi

Git bisect, bir gerilemeye neden olan commit'i bulmak için kullanılan bir araçtır. Merge kullanırken, git bisect her iki ebeveyni de dikkate alarak birleştirme commit'lerini doğru şekilde geçer. Rebase ile bisect daha hızlı çalışır çünkü geçmiş doğrusaldır ve dallanma gerektirmez. Ancak, commit'ler ekibe duyurulduktan sonra rebase yapıldıysa, orijinal SHA'lar kaybolur ve bisect sorunlu commit'i bulamayabilir.

Rebase Ne Zaman Kullanılır

Rebase üç senaryoda idealdir: Pull Request için bir özellik dalı hazırlamak, kişisel bir dalı main/develop'ın mevcut durumuna güncellemek ve birleştirmeden önce geçmişi temizlemek. Her durumda, rebase ekip çalışmasını riske atmadan geçmiş okunabilirliğini artırır.

Pull Request öncesinde, taslak commit'leri (WIP, inceleme sonrası düzeltmeler) anlamlı mantıksal birimler halinde birleştirmek için etkileşimli rebase yapılması önerilir. Bu, kod incelemesini kolaylaştırır: inceleyen kişi 15 küçük commit değil, net mesajlarla 3-5 yapılandırılmış değişiklik görür.

Bir özellik dalını güncellemek için rebase, gereksiz birleştirme commit'leri oluşturmadığından merge'e tercih edilir. Özellik dalı içinde periyodik olarak git rebase develop çalıştırırsanız, nihai birleştirmede 10 birleştirme commit'inden oluşan bir basamak olmaz — develop üzerinde yalnızca temiz özellik commit'leri olur.

Birleştirmeden önce etkileşimli rebase ile geçmiş temizliği, küçük düzeltmeleri (yazım hataları, biçimlendirme) gizlemeye ve commit'leri işlevselliğe göre gruplandırmaya olanak tanır. Git mesajları, otomatik changelog oluşturan Conventional Commits kuralına (fix:, feat:, refactor:, docs:) uymalıdır.

Rebase'in Riskleri ve Kuralları

Rebase yanlış uygulanırsa tehlikeli bir işlemdir. Ana risk, yayınlanmış geçmişi yeniden yazmaktır. Bir geliştirici, başkalarının zaten gönderdiği ve kullandığı bir dalı rebase ederse, yerel kopyaları senkronizasyonu kaybeder ve veri kaybı riskiyle force-pull yapmak zorunda kalırlar.

  • Altın kural: ortak depoda zaten var olan commit'leri asla rebase etmeyin. Bu, ekip üyelerinin erişebildiği tüm dallar için geçerlidir
  • Force push: yerel bir özellik dalını rebase ettikten sonra, --force'dan daha güvenli olan --force-with-lease bayrağı ile push yapılması gerekir çünkü sunucuda dalı başka birinin güncelleyip güncellemediğini kontrol eder
  • Bağlam kaybı: rebase, özellik dalının ne zaman ve hangi daldan oluşturulduğu bilgisini yok eder. Dal oluşturma tarihlerini korumak önemliyse merge kullanın
  • Çakışmalar: rebase sırasında, çakışmalar her commit için ayrı ayrı çözülmelidir, bu da çok sayıda commit ile yorucu olabilir

Riskleri en aza indirmek için şu kuralı izleyin: yalnızca yayınlanmamış kişisel dallar için rebase yapın. Bir dal zaten ortak depoda bulunuyorsa, --no-ff ile merge kullanın. Yayınlanmış bir dalı rebase etmeniz gerekiyorsa, ekibi önceden uyarın ve force push'u koordine edin.

Tehlikeli rebase'e karşı otomatik koruma, sunucu tarafı hook'lar aracılığıyla uygulanır: Git sunucusundaki pre-receive hook, push'un yayınlanmış commit'leri yeniden yazıp yazmadığını kontrol edebilir. GitHub ve GitLab, korumalı dallar için yerleşik koruma sağlar — bir yönetici korumayı kaldırmadıkça force push engellenir.

Sıkça Sorulan Sorular

Herkese açık bir dalı rebase ederseniz ne olur?

Dalın geçmişi değişir — commit SHA'ları farklı olur. Bu dalı zaten göndermiş veya ondan alt dallar oluşturmuş olan herkes git pull yaparken çakışmalarla karşılaşır. Kurtarma, manuel müdahale gerektirir ve commit kaybına yol açabilir.

Rebase geri alınabilir mi?

Tamamlanmadan öncegit rebase --abort. Tamamlandıktan sonra — yalnızca git reflog aracılığıyla, rebase yakın zamanda yapıldıysa. reflog, HEAD hareketlerinin geçmişini saklar ve bu sayede rebase öncesi duruma dönülebilir: git reset --hard HEAD@{1}.

Rebase, cherry-pick'ten nasıl farklıdır?

Rebase bir dizi commit'i yeni bir tabana taşır. Cherry-pick bir veya daha fazla belirli commit'i mevcut dala uygular. Rebase tüm zincir için otomatiktir, cherry-pick her commit'in manuel olarak seçilmesini gerektirir.

Her Pull Request'ten önce rebase yapılmalı mı?

Önerilir, ancak zorunlu değildir. PR öncesi rebase, dalı main/develop'ın mevcut durumuna günceller ve geçmişi temizler. Dal yakın zamanda oluşturulduysa ve güncelleme gerektirmiyorsa, commit'leri temizlemek için etkileşimli rebase yeterlidir.

Rebase etiketleri nasıl etkiler?

Etiketler rebase sırasında taşınmaz. Rebase edilmiş bir commit'te etiket varsa, bu etiket artık dal geçmişinin parçası olmayan eski commit'te kalır. Özellik dallarındaki commit'lere değil, yalnızca main'e etiket eklenmesi önerilir.

Özet

  • Rebase — commit'leri yeni bir tabana yeniden temellendirme, doğrusal geçmiş oluşturma
  • Merge'ten farklı olarak birleştirme commit'i oluşturmaz ve commit SHA'larını yeniden yazar
  • Etkileşimli rebase commit'leri sıkıştırmaya, yeniden adlandırmaya ve silmeye olanak tanır
  • Altın kural: yalnızca kişisel dalları rebase edin, asla herkese açık dalları
  • Rebase'den sonra force push gerekir (tercihen --force-with-lease)
  • Pull Request için rebase + -i ile geçmiş temizliği önerilir
  • Karma yaklaşım: özellik dalını güncellemek için rebase, sonlandırmak için --no-ff merge

Anahtar teslim bir mobil uygulama geliştireceğiz

IT Sectr, 2017'den beri girişimler ve işletmeler için iOS ve Android uygulamaları oluşturmaktadır. Size danışmanlık yapacak ve en iyi çözümü önereceğiz.

Projeyi tartış

Ayrıca okuyun