Git History, komutu 20 Nisan 2026'da yayınlanan 2.54 versiyonu ile Git dünyasına dahil edildi. Bu komut, bir commit'in mesajını değiştirmek istediğimizde ve bir commit'i bölmek istediğimizde devreye girer. Aslında yeni bir şey getirmez halihazırda git rebase komutu ile yapılanları sadeleştirir ve kısaltır.
Git History vs Git Rebase
Rebase'in aslında yaptığı iş iki ayrı şeydir.
- Commit'leri yeni bir tabana taşımak (asıl işi).
- Taşırken commit'leri düzenlemek (yan iş).
Burada kilit nokta şu: git rebase -i komutu ikisini birlikte yapıyor. Ama çoğu durumda geliştiriciler sadece 2 numarayı istiyor. Yani sadece "şu commit'in mesajını değiştir" diyor.
History tam da bu noktada devreye giriyor.
O yan işi alıyor bağımsız bir komut yapıyor. Commit'leri gerekmediği için yerinden oynatmıyor ve working tree'ye de dokunmuyor. Doğrudan geçmişe gidip tek bir şeyi değiştiriyor. Bunu şu benzetmeyle düşünelim:
- rebase -i binayı yıkıp yeniden inşa et ama bu sefer bazı odaları farklı yap.
- git history sadece o odanın boyasını değiştir.
Git History Komutu Nasıl Çalışır? Rebase'e Göre Avantajları Nedir?
Şöyle düşünelim, Git'te bir commit'i düzenlemek istiyoruz. Bunun için klasik yol git rebase -i komutudur. Ama rebase, birden fazla adımdan oluşur.
- Çalışma ağacını etkiler
- Index'i değiştirir
- Çakışma olunca ortada kalma sorunu olabilir
- Sadece bir typo düzeltmek için bile to do list hazırlamak gerekir
git history ise daha odaklı bir araçtır. Şu an iki görevi üstleniyor: bir commit'in mesajını değiştirme ve bir commit'i bölme (önceden bu iki işlem için git rebase -i kullanılıyordu).
Git history komutunun dikkat çeken farklarından biri, çalışma dizini olmadan da kullanılabilmesidir. Normalde git rebase -i gibi geçmiş düzenleme komutları dosyaların bulunduğu bir çalışma alanına ihtiyaç duyar. git history ise commit geçmişini doğrudan değiştirdiği için buna gerek duymaz. Bu sayede yalnızca .git klasöründen oluşan depolarda bile çalışabilir. Özellikle sunucu tarafında veya otomatik bakım işlemlerinde bu önemli bir kolaylık sağlar.
Git History ile bir commit'in mesajını değiştirme
git history reword <commit> komutu bir commit'in mesajını değiştirir. Çalışma dizinine (working tree) ve index'e dokunmaz. O commit'i temel alan ilgili branch referanslarını otomatik olarak günceller.
git history reword abc1234
# editör açılır ve mesajı değiştiririz.
Aynı işlemi git rebase ile yapmak istersek
# git rebase'de aynı işlem
git rebase -i HEAD~3
# listede commit'i reword olarak işaretle.
# kaydet ve çık.
# editör açılır, mesaj değiştirilir.
# rebase tamamlanır.
Fark açık: rebase 4-5 adımdan oluşurken git history reword 1 adımdır.
Git History ile bir commit'i bölme
git history split <commit> komutu, tek bir commit içindeki değişiklikleri iki ayrı commit'e ayırmak için kullanılır. git add -p gibi çalışır. Hangi değişikliklerin ayrı bir commit'e çıkarılacağını seçeriz.
git history split HEAD
# diff getirilir, hunklar seçilir.
# git iki ayrı commit oluşturur.
Hangi Durumda Rebase, Hangi Durumda History Kullanılır?
git history komutu Rebase'den bazı görevleri üstlense de bazı durumlarda hala git rebase komutu gerekiyor. Aşağıda hangi durumlarda hangisi kullanılmalı tablosunu inceleyebilirsiniz.
| İhtiyaç | Araç |
|---|---|
| Commit mesajı düzeltme | git history reword |
| Commit'i ikiye böl | git history split |
| Commit'leri yeniden sırala | git rebase -i |
| Commit'leri birleştir (squash) | git rebase -i |
| Branch'ı yeni bir tabana taşı | git rebase |
| Merge commit'li geçmişte düzenleme | git rebase -i |
Git History Hangi Durumlarda Kullanılamaz?
- Git history merge commit içeren geçmişlerde çalışmaz. Bunun için hala git rebase -i kullanılmalıdır.
- Git history komutu eğer çakışmaya yol açacaksa çalışmayı reddeder.
- Hala deneysel olduğu için arayüzü değişebilir. Bu konuda çekinceleriniz varsa kullanmayı erteleyebilirsiniz.
git history komutunun şu anki önemli sınırlamalarından biri, merge commit içeren geçmişlerde çalışmamasıdır. Çünkü merge commit'ler normal commit'lerden farklı olarak birden fazla geçmişi birleştirir. git history ise daha çok düz bir commit sırası üzerinde küçük düzenlemeler yapmak için tasarlanmıştır. Eğer geçmişte merge commit varsa Git bu işlemi riskli gördüğü için komutu çalıştırmaz. Daha karmaşık geçmiş düzenlemelerinde bu nedenle hâlâ git rebase -i kullanmak gerekir.
Özetle; Rebase hala gerekli bir araç ama çok güçlü bir araç olduğundan basit işler için riskli olabilir. Git geliştirici ekibinin yaptığıysa onun bazı özelliklerini git history'e aktarmak olmuuş. Yazının başında da belirttiğimiz gibi git history komutu Git'e yeni bir yetenek katmıyor ama aynı sonucu daha az adımda (ve daha az riskli) yapılmasını sağlıyor. Rebase'in "basit durumlar için fazla karmaşık" olduğu yerleri dolduruyor.