Git 2.56'nın deneysel history drop komutu, commit'leri rebase'e göre 77 kata kadar daha hızlı yeniden yazıyor

Git 2.56, geçmişten bir commit silmenin daha hızlı bir yolunu getiriyor

28 Eylül 2026'da yayımlanan Git 2.56, drop, fixup, reword ve split olmak üzere dört deneysel alt komut içeren yeni bir git history komutunu içeriyor. En dikkat çekeni, geçmişin ortasından bir commit'i kaldıran ve silinen commit'in üstündeki tüm torun commit'leri, kaldırılan commit'in ebeveyni üzerine yeniden oynatan drop komutu — worktree ve checkout olmadan, doğrudan bare bir repository üzerinde çalışıyor. Sürüm henüz Ubuntu'nun apt depolarında bulunmadığı için v2.56.0 etiketli kaynak kodu derlenerek hazırlanan ve dev.to'da yayımlanan pratik bir benchmark, yeni komutun geleneksel worktree-ve-rebase iş akışına göre 40 ila 77 kat daha hızlı çalıştığını ölçtü.

Benchmark sayıları

dev.to yazarı, bir kök commit, bir hedef commit ve değişen sayıda torun commit içeren yeni test repository'leri oluşturdu, ardından her birini iki kez bare olarak klonladı ki iki yöntem de özdeş geçmişle başlasın. Eski yol — bağlı bir worktree ekleme, git rebase --onto çalıştırma ve worktree'yi kaldırma — 20 torun commit ile ortalama 1,4 saniye, 100 ile 7,1 saniye ve 400 ile 26,5 saniye sürdü. git history drop aynı boyutlar için ortalama 0,035, 0,092 ve 0,36 saniye sürdü; bu da 40,7x, 77,5x ve 73,2x oranları demek. Sonuçta ortaya çıkan ağaçlar iki yöntem arasında birebir aynıydı — yeniden yazılan dalın ağaç karması tam olarak eşleşti — yani hız köşe kesmekten gelmiyor; yalnızca commit karmaları, taze zaman damgaları nedeniyle farklıydı.

Hızlanma gerçekte nereden geliyor

Sezgisel açıklama — worktree kurulumunu atlamak — yanlış çıkıyor. Worktree ekleme ve kaldırma birlikte 25 saniyelik bir çalışmanın yalnızca 26 milisaniyesini alıyor. Pahalı olan kısım rebase'in kendisi: git rebase --onto, commit'leri tek tek cherry-pick ediyor ve bu ara durumlar hiçbir zaman kullanılmasa bile her adımda index'i ve çalışma ağacını güncelliyor. Yalıtılmış rebase çalışması, 400 commit'i yeniden oynatmak için yalnızca sistem süresi olarak kabaca altı saniye gösterdi. git history drop, drop, reword veya split işlemleri için çalışma ağacına hiç dokunmuyor; tamamen .git içindeki nesneler üzerinde çalışıyor, bu yüzden maliyeti commit başına dosya sistemi yazımlarından değil, gerçek diff işinden kaynaklanıyor.

Rebase'ten iki davranış farkı

Birincisi, --update-refs=branches ile komut, yalnızca geçerli dalı değil, silinen commit'in tüm torun dallarını güncelliyor. Yazarın testinde tek bir çağrıdan sonra hem main hem de bir feature dalı ilerledi; rebase bu durumda her dal için ikinci ve ayrı bir çalışma gerektirirdi.

İkincisi, hook çalıştırmıyor. Rebase altında hemen tetiklenen çalıştırılabilir bir post-rewrite hook, git history drop altında hiç tetiklenmedi. Man sayfası hook'ların şu anda çalıştırılmadığını ve bunun değişebileceğini kabul ediyor, ancak bu sürüm itibarıyla post-rewrite'a dayanan her otomasyon — bot bildirimleri, önbellek geçersiz kılma, lint — bir betik geçiş yaparsa sessizce çalışmayı kesiyor.

Hatalar hiçbir şey bırakmıyor

Komut üç işlemi doğrudan reddediyor: üzerine yeniden oynatılacak bir ebeveyn bulunmadığı için kök commit silme; merge commit silme; ve yeniden oynatması çakışacak herhangi bir silme. Üçü de hemen, sıfırdan farklı bir çıkış durumuyla başarısız oluyor. Çakışma durumunda yazar hiçbir şeyin değişmediğini doğruladı — çakışma işaretçileri yok, rebase durum dizini yok, yarım kalmış bir yeniden yazım yok. Man sayfası durumsuz yeniden yazımları bir tasarım sınırlaması olarak sunuyor, ancak kirli bir çalışma ağacında dizinin ortasında duran interaktif bir rebase ile karşılaştırıldığında, atomik biçimde başarısız olmak daha çok bir özellik gibi okunuyor. Ayrıca basit bir metinsel önizleme yerine ref güncellemelerini git update-ref --stdin biçiminde çıktılayan bir --dry-run bayrağı da var.

Neden önemli

Paylaşılan geçmişin ortasından bir commit silmek rutin bir bakım işidir ve şu ana kadar bu, tam bir checkout artı yeniden oynatılan her commit için bir index-ve-worktree güncellemesi bedeli ödemek anlamına geliyordu — geçmiş uzunluğuyla büyüyen ve sunucularda ile CI koşucularında en çok canını sıran bir maliyet. Nesneleri doğrudan yeniden yazmak bu ek yükün büyük kısmını ortadan kaldırıyor ve aynı komut, rebase'in iki tekrarlayan sorununu da çözüyor: torun dallar tek seferde güncelleniyor ve çakışan bir yeniden yazım geride bir enkaz bırakmak yerine temizce iptal oluyor. Deneysel etiketi, betiklerin davranışı kararsız olarak görmesi gerektiği anlamına geliyor — man sayfası değişebileceği konusunda uyarıyor ve eksik hook'lar gerçek bir göç riski — ancak uzun ömürlü repository'leri koruyan herkes için bu, takip etmeye değer bir iş akışı değişikliği.