Git Revert vs Reset: Geçmişinizi Hangisi Kurtarır?

TL;DR: git revert, eski bir commit’i geri alan yeni bir commit ekler — geçmiş korunur; başkalarının pull’ladığı branch’lerde güvenlidir. git reset branch işaretçisini geriye taşır — geçmiş yeniden yazılır; yalnızca pushlamadığınız commit’lerde güvenlidir. Paylaşılan branch’lerde revert, yerel temizlikte reset kullanın. reset --hard, commitlenmemiş çalışma alanı değişikliklerini de siler; gerçek işi yiyen odur.

git revert ile git reset arasındaki fark nedir?

İkisi de projenizin, geçmişteki bir commit hiç yaşanmamış gibi görünmesini sağlar. Nasıl konusunda anlaşamazlar:

• git revert <sha> bir commit’in ters yamasını hesaplar ve onu commit’ler. Geçmişiniz, “şunu geri al” diyen bir commit ile bir satır uzar. Kötü commit logda kalır, peşinden iptali gelir. Diğer her şeyin SHA’larına dokunulmaz.
• git reset <sha> güncel branch’in işaretçisini <sha>ya taşır. Sonrasındaki commit’ler koparılır — çöp toplamaya dek nesne veritabanında dururlar ama hiçbir branch’ten ya da git log‘dan artık ulaşılamazlar.

Biri hiçbir şeyi yeniden yazmaz; öteki hiçbir şey olmamış gibi davranır. Her durumun hangisini istediğine bu tek özellik karar verir:

# Demo: çalıştırılıp atılabilecek bir repo
git init /tmp/revert-vs-reset && cd /tmp/revert-vs-reset
echo one > file.txt && git add . && git commit -m "one"
echo two > file.txt && git add . && git commit -m "two"

# Revert: geçmiş iki commit'i de tutar; "two"yu geri alan bir üçüncü ekler
git revert --no-edit HEAD
git log --oneline        # 3 commit: revert, two, one

# Reset: branch işaretçisi geriye kayar, "two" logdan kaybolur
git reset --hard HEAD~1
git log --oneline        # 1 commit: one

İkisini de çalıştırıp git log‘a bakın — asimetri, cevabın tamamıdır.

git reset —soft, —mixed ve —hard aslında ne yapar?

Üç mod, işaretçi kaydıktan sonra değişikliklerinizin nerede kaldığını kontrol eder:

Mod	Branch işaretçisi	Staging alanı	Çalışma alanı	Düzenlemeleriniz
--soft	geriye kayar	staged kalır	dokunulmaz	tamamen korunur
--mixed (varsayılan)	geriye kayar	unstaged	dokunulmaz	korunur, unstaged
--hard	geriye kayar	sıfırlanır	sıfırlanır	silinir

Tablonun somut okumaları:

• git reset --soft HEAD~1 — “Çok erken commit’ledim.” Her şey staged olarak geri döner; yeniden commit’lenmeye, belki üstüne yeni işle birlikte, hazırdır.
• git reset HEAD~1 (mixed) — “Yanlış dosyaları staging’ledim.” Düzenlemeler çalışma alanında sağ kalır, hiçbir şey staged değildir. Başıboş dosyaların da gitmesini istiyorsanız git remove untracked files yazısıyla eşleştirin.
• git reset --hard HEAD~1 — “Bu commit de, commitlenmemiş düzenlemelerim de çöp.” Git iki kez sormaz; çalışma alanı tarafı için stash’lemediniz ya da commit’lemedinizse geri alınacak bir şey yoktur.

revert‘in modu yoktur, çünkü hiçbir şeyi yok etmez — yalnızca dengeleyici bir commit ekler.

git reset yerine ne zaman git revert kullanmalısın?

Tek sorun: bu commit’i başkası pull’ladı mı? Cevap evetse reset masadan kalkar.

Başkalarının üzerine iş kurduğu bir branch’i resetlemek, paylaşılan geçmişi yeniden yazar. Onların sonraki pull’ı ayrışan branch’lerle karşılaşır ve “çözüm”, hatanızı herkesin problemine çeviren bir force-push olur çoğu zaman. Revert normal bir commit ekler; düz bir git pull herkes için temizce birleşir — revert’in main‘de ve GitHub pull request’lerinde varsayılan cevap olmasının sebebi budur; “Revert” düğmesi, birleştirilmiş bir PR’ın geçmişini yeniden yazmanın seçenek olmadığı yerde tam olarak bu yüzden durur.

Reset, paylaşımdan önceki pencere içindir: otuz saniye önce yaptığınız commit, staging yanılgısı, yerel deneme branch’i. İşin tek kopyası sizin makinenizde yaşıyorsa geçmişi yeniden düzenlemekte özgürsünüz — push öncesi pencerenin tüm anlamı budur.

Orta bir durum da var: kendi feature branch’inize pushladınız ve kimse üzerine inşa etmiyor. Orada reset sonrası force-push toplumsal kabul görür; yine de revert daha az koordinasyon maliyetidir. Force-push’ı yalnızca tek sahibi olduğunuz branch’lere saklayın.

Paylaşılan branch’lerde git revert, git reset’ten daha güvenli mi?

Evet — gelenek gereği değil, yapısal olarak:

• Revert sıradan bir commit üretir; CI üzerinde çalışır, diff’i gözden geçirilebilir ve git log, yarınki size değişikliğin neden kaybolduğunu anlatır.
• Reset, aradaki hâli sessizce çöpe atar. Sonradan bakan biri neyin, ne zaman geri alındığını göremez; çünkü log, onu hiç içermeyen düz bir çizgi gösterir.

İki pratik keskin kenar:

• Bir merge commit’ini geri almak git revert -m 1 <sha> ister (ilk ebeveynin çizgisini korursunuz). -m olmadan git reddeder ve hatayı okumak size kalır.
• Revert bir zaman makinesi değildir: tek bir commit’in diff’ini geri alır. Sonraki commit’ler aynı satırlara dokunduysa çakışma çözmeniz gerekebilir — bu, git’in size “geri alma iç içe geçmiş” demesidir; arıza değil, faydalı bilgidir.

Özellikle en son commit’inizi geri almak istiyorsanız — değişikliklerini koruyarak ya da atarak — seçenekler son commit’i geri almak: değişiklikleri korumak yazısında sıralanır.

git restore ne işe yarar, resimdeki yeri neresi?

git restore (ve ikisi olan git switch), 2.23 sürümünde geldi; reset’in isim kalabalığı yüzünden kötü yaptığı işleri devraldı:

Görev	Eski yöntem	Net yöntem
Bir dosyadaki çalışma alanı düzenlemelerini at	git checkout -- file / git reset --hard	git restore file
Bir dosyayı staging’den çıkar	git reset HEAD file	git restore --staged file
Branch’i başka bir commit’e taşı	git reset <sha>	git reset <sha> (yerine geçen yok — bu kalır)

Yani modern bölüşüm: restore dosyaları düzeltir, reset branch taşır, revert yayımlanmış commit’leri geri alır. Arama önerileri, insanların “git revert vs reset vs restore”u birlikte arattığını gösterir — haklı bir sebeple; üç komuta bölünmüş tek zihinsel modeldir onlar. Eski git checkout biçimleri her yerde çalışmaya devam eder; yenileri tek yapmanız istenen bir dosyayı staging’den çıkarırken bütün bir branch’i kıyıcıya göndermenizi engeller.

Amaçınız kötü bir commit’i silmek değil, iyi bir commit’i ileriye taşımaksa o iş cherry-pick’tedir: git cherry-pick: çok commit, branch, çakışma.

Hızlı karar özeti

1. Commit herkese açık (pushlandı, başkaları pull’ladı) → git revert <sha>.
2. Commit yalnızca yerelde, yeniden yapmak istiyorsunuz → git reset --soft ya da --mixed ve yeniden commit.
3. Yalnızca yerelde, commitlenmemiş dağınıklıkla birlikte yok olmasını istiyorsunuz → git reset --hard; ama önce çalışma alanında başka ne var, dürüstçe bir bakın.
4. Tek dosya zedelendi → git restore <file> ve branch’e dokunmayın.

Listedeki tek gerçekten tehlikeli satır --hard‘dır — geri kalanının hepsi git reflog ile geri konuşulabilir. Git’te kalıcı kayıplar dardır ve çoğunlukla sizin onu elle yazmanızı gerektirir; inşa edilecek alışkanlık, --hard‘dan önce yarım saniye duraklamaktır, git’in keskin aletlerinden tamamen kaçınmak değil.