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 (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 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 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.
# 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.
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.
# 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.
--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 (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.
# 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 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.
| Kriter | Merge | Rebase |
|---|---|---|
| Geçmiş | Dallanmayı korur | Doğrusal, dalsız |
| Birleştirme commit'i | Oluşturulur (ff hariç) | Oluşturulmaz |
| Commit SHA | Değişmez | Yenileri oluşturulur |
| Güvenlik | Herkese açık dallar için güvenli | Tehlikeli — geçmişi yeniden yazar |
| Log okunabilirliği | Dallanma grafiği | Düz çizgi |
| git bisect | Kullanışlı — birleştirme noktası görünür | Kullanış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, 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 üç 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 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.
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
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.
Tamamlanmadan önce — git 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 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.
Ö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.
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
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.
Ayrıca okuyun