Git'te Son Commit'i Geri Al: Değişiklikler Kalsın

TL;DR: son commit’i geri alıp değişiklikleri korumak için git reset --soft HEAD~1 (değişiklikler staged kalır) ya da git reset HEAD~1 (değişiklikler working tree’de kalır) çalıştırın. Commit zaten push edildiyse onun yerine git revert HEAD — geçmişi yeniden yazmadan geri alan yeni bir commit oluşturur. Bu üç komut, “erken commit’ledim” anlarının neredeyse tamamını kapatır. Bu rehberin geri kalanı her durumu kopyala-yapıştır komutlarla ele alır, --soft, --mixed ve --hard farkını açıklar ve bir şey ters giderse kurtarma yolunu gösterir. Aşağıdaki komutların hepsi Linux, macOS ya da Windows’taki güncel her Git kurulumunda çalışır.

Son commit’i nasıl geri alırım ama değişiklikleri korurum?

En yaygın durum: commit’lediniz, sonra bir yazım hatası ya da eksik bir dosya gördünüz, ya da değişikliğin başka bir commit’e ait olması gerektiğini fark ettiniz. Henüz hiçbir şey push edilmedi. Commit’i geri alın ve her şeyi yerine koyun:

# Commit geçmişte hiçbir yerde kalmaz — değişiklikler staging area'ya döner
git reset --soft HEAD~1

# Değişiklikler bunun yerine working tree'ye (unstaged) döner
git reset HEAD~1

HEAD~1, “HEAD’in şu an gösterdiği yerden bir commit önce” demektir. İki komuttan birinden sonra dosyalarınız diskte dokunulmamış halde — yalnızca branch göstergesi hareket etti. git status ile doğrulayın: --soft ile değişiklikler staged‘dir, düzeltmeler katılmış halde yeniden commit’e hazırdır; flagsiz ise unstaged‘dir, önce rahatça düzenleyebilirsiniz.

Sadece son commit’e dosya eklemek istiyorsanız daha güvenli alışkanlık, onu hiç geri almamaktır:

git add forgotten-file.txt
git commit --amend --no-edit

--amend son commit’i yerinde değiştirir (burada commit mesajı değişmiyor). Push edilmiş bir commit’i amend etmenin geçmişi yeniden yazdığını unutmayın — aşağıda değineceğiz.

—soft, —mixed ve —hard arasındaki fark nedir?

Ezberlenmeye değer kısım burası, çünkü flag, değişikliklerinizin nerede bittiğine — ve kaybedilip kaybedilemeyeceğine — karar verir:

Flag	Commit geri alındı mı?	Değişiklikler diskte	Staged mı?	Tipik kullanım
--soft	Evet	Korunur	Evet	Küçük düzeltmelerle yeniden commit
--mixed (varsayılan)	Evet	Korunur	Hayır	Değişiklikleri yeniden gruplamak, seçerek stage etmek
--hard	Evet	Silinir	—	İşi tamamen çöpe atmak
git revert	Hayır (yeni commit)	Korunur	—	Zaten push edilmiş bir commit’i geri almak

--hard tehlikeli olan tek flag: commit’i ve değişiklikleri atar. Herhangi bir reset --hard öncesinde elinizdekini stash’leyin ya da bir branch’e alın:

git branch backup-before-reset   # ucuz sigorta
git reset --hard HEAD~1          # commit + değişiklikler gitti

Tehlikeli versiyonu çoktan çalıştırdıysanız her şey kaybolmuş değil — git reflog, HEAD’in nereden geçtiğini hatırlar:

git reflog                       # kaybettiğiniz commit hash'ini bulun
git reset --hard HEAD@{1}        # ya da: git reset --hard <hash>

Reflog, sahipsiz commit’leri varsayılan olarak yaklaşık 90 gün tutar; çöp toplama (garbage collection) başlamadan hareket ederseniz “yanlışlıkla hard reset yaptım” neredeyse her zaman kurtarılabilir.

Commit’i çoktan push ettiysem ne yapmalıyım?

Commit paylaşılan bir branch’teyse (kendi feature branch’iniz dışındaki her şey), geçmişi yeniden yazmayın. Ters değişikliği hesaplayıp onu commit eden git revert kullanın:

git revert HEAD
git push

Çeken herkes, eski commit’in değişikliklerini kaldıran yeni bir commit alır. Force-push yok, bozulan meslektaş yok. Bir dizi commit’i geri almanız gerekirse aralığı revert edin: git revert --no-commit HEAD~3..HEAD && git commit.

Alternatif — git reset --hard HEAD~1 && git push --force-with-lease — yalnızca kimsenin üzerine inşa etmediği bir branch’te kabul edilebilir ve --force-with-lease (asla çıplak --force değil) tek güvenli formdur, çünkü bu sırada biri push etmişse reddeder. Paylaşılan branch’lere force-push, ekiplerin commit kaybettiği ve CI loglarının gizemli biçimde kimsenin checkout’uyla eşleşmediği yöntemdir.

Son commit’i nasıl geri alırım ama bir kenara saklarım?

Bazen commit iyi bir iştir ama yanlış adrestedir — yanlış branch’tedir ya da çok erkendir. Geri almak yerine taşıyın:

git branch stash-commit          # commit'i yeni bir branch'e park et
git reset --hard HEAD~1          # sonra mevcut branch'i temizle

Ya da mevcut branch’inize dokunmadan yalnızca o commit’i başka bir branch’e alın:

git cherry-pick <hash>           # hedef branch'teyken

reset --soft, cherry-pick ve revert arasında taşıyamayacağınız ya da etkisizleştiremeyeceğiniz commit yoktur — püf noktası, flag’e uzanmadan önce “taşı” ile “geri al” arasında karar vermektir.

Hangi geri alma yöntemini kullanmalıyım? Hızlı karar rehberi

1. Push edilmedi, düzeltip yeniden commit’leyeceğim → git reset --soft HEAD~1
2. Push edilmedi, seçerek yeniden stage edeceğim → git reset HEAD~1 (mixed)
3. Değişikliklerin tamamen gitmesini istiyorum → git reset --hard HEAD~1 (pişman olursanız reflog bilir)
4. Paylaşılan bir branch’e çoktan push edildi → git revert HEAD
5. Commit başka bir branch’e ait → geri almayın, cherry-pick

Son bir operasyonel not: kötü bir commit bir sunucuya ulaştıysa — bozuk bir deploy hook’u, force-push sonrası ters giden bir CI runner — bakılacak bir sonraki yer Git değil, makinenin loglarıdır. Herhangi bir systemd makinesinde journalctl -u <service> -n 100, neyin ne zaman çalıştığını tam olarak gösterir; journalctl cheat sheet kopyala-yapıştır desenleri içeriyor. Ve iş akışınızda diff incelemesi için yerel LLM araçları varsa, iki ana seçeneği Ollama vs LM Studio yazısında karşılaştırdık.