Git'te Commit Nasıl Geri Alınır? Revert, Reset ve Restore

Hangi durumda hangi komut?

Git'te geri alma tek bir komut değildir; üç farklı komut üç farklı ihtiyaca cevap verir. Karar verirken önce şunu sorun: bu commit başkalarıyla paylaşıldı mı?

Commit yalnızca sizin makinenizdeyse, geçmişi geri sarmak güvenlidir ve reset uygun olur. Commit uzak depoya gönderildiyse ve başkaları bu dalı çekmiş olabilirse, geçmişi yeniden yazmak onların deposunu bozar; bu durumda revert kullanılır. Commit'e hiç dokunmadan yalnızca bir dosyanın içeriğini önceki haline döndürmek istiyorsanız restore yeterlidir.

Bu sayfa commit'i bilerek geri alma yöntemlerini anlatır. Yanlışlıkla geri alınmış ya da kaybolmuş bir commit'i kurtarmak ayrı bir konudur.

git revert: paylaşılmış commit için güvenli yol

git revert, belirtilen commit'in yaptığı değişikliğin tersini uygulayan yeni bir commit oluşturur. Eski commit geçmişte durur; yanına onu etkisiz kılan bir commit eklenir. Bu yüzden başkalarının deposuyla uyumsuzluk oluşmaz ve normal bir push yeterlidir.

Temel kullanım:

• git revert HEAD: Son commit'i geri alan yeni bir commit oluşturur ve mesaj için editör açar.
• git revert HEAD --no-edit: Aynı işlemi editör açmadan, varsayılan mesajla yapar.
• git revert <commit-kimliği>: Geçmişteki belirli bir commit'i geri alır.

Bir merge commit'ini geri alırken Git, hangi tarafın ana hat sayılacağını bilmez. Bu yüzden -m parametresiyle üst commit numarası verilir; örneğin git revert -m 1 <merge-commit> komutu, birinci üst commit'i ana hat (mainline) kabul ederek tersini uygular. Merge geri alındığında aynı dalın daha sonra tekrar merge edilmesi için ek adımlar gerekebilir, bu nedenle bu işlem dikkatle planlanmalıdır.

Revert çakışma çıkarırsa, tıpkı bir merge çakışması gibi çözülür ve işlem tamamlanır; iptal etmek için git revert --abort kullanılır.

Örnek: Bir ekip arkadaşınız yanlışlıkla ortak dala hatalı bir yapılandırma değişikliği gönderdi ve herkes bu dalı çekiyor. git log ile commit kimliğini bulur, git revert <commit-kimliği> komutunu çalıştırırsınız. Git, tersini uygulayan yeni bir commit oluşturur ve siz normal push ile gönderirsiniz. Ekip dalı çektiğinde değişiklik hem eklenmiş hem geri alınmış olarak görünür; geçmiş tutarlı kalır.

git reset: soft, mixed ve hard farkı

git reset, dalın işaret ettiği commit'i değiştirerek geçmişi geri sarar. Kip seçimi, commit'teki değişikliklerin ne olacağını belirler.

• git reset --soft HEAD~1: Son commit geri alınır, ancak değişiklikler hazırlık alanında hazır bekler. Commit mesajını düzeltmek ya da son commit'leri birleştirmek için kullanışlıdır.
• git reset --mixed HEAD~1 (varsayılan kip, yalnızca git reset HEAD~1 de aynıdır): Commit geri alınır, değişiklikler çalışma dizininde kalır ama hazırlık alanından çıkar. Hangi dosyaların yeniden commit edileceğini baştan seçmek istediğinizde uygundur.
• git reset --hard HEAD~1: Commit ve değişiklikler tamamen atılır; hem hazırlık alanı hem çalışma dizini commit'in haline döner. Henüz commit edilmemiş değişiklikler de kaybolabilir.

Hard kipi en riskli olandır. Çalıştırmadan önce git status ile bekleyen değişiklikleri kontrol edin; saklamak istediğiniz bir şey varsa önce commit edin ya da stash'e alın.

Örnek: Henüz push etmediğiniz bir commit'e yanlış dosyayı eklediğinizi fark ettiniz. git reset --soft HEAD~1 ile commit'i geri alır, değişiklikler hazırlık alanında beklerken yanlış dosyayı çıkarır ve doğru içerikle yeniden commit edersiniz. Dosya çalışma dizininde kaybolmadığı için işiniz boşa gitmez.

git restore: dosya düzeyinde geri alma

git restore, commit geçmişini değiştirmez; belirtilen dosya ya da dizinleri başka bir sürümden geri getirir. Commit etmeden yaptığınız bir düzenlemeyi atmak ya da bir dosyayı hazırlık alanından çıkarmak için idealdir.

• git restore dosya.txt: Çalışma dizinindeki dosyadaki kaydedilmemiş değişiklikleri atar ve hazırlık alanındaki ya da HEAD'deki sürüme döndürür.
• git restore --staged dosya.txt: Dosyayı hazırlık alanından çıkarır, değişiklikler çalışma dizininde kalır.
• git restore --source=<commit> dosya.txt: Dosyayı belirli bir commit'teki haline döndürür.

Son komut kullanışlıdır: tüm commit'i geri almak yerine yalnızca bir dosyanın eski halini alırsınız. Çalışma dizinindeki değişiklikleri atan restore komutu geri dönüşsüzdür; çalıştırmadan önce değişikliklerin gerçekten gereksiz olduğundan emin olun.

Push edilmiş commit'i geri alırken dikkat edilecekler

Commit uzak depoya gönderildiyse en güvenli yol revert'tir: yeni bir commit oluşturur, normal push ile gönderirsiniz, kimsenin geçmişi bozulmaz.

Push edilmiş commit'te reset kullanırsanız, yerel geçmişiniz uzak depodan ayrışır ve normal push reddedilir. Bunu aşmak için zorla push gerekir. Zorla push, uzak daldaki geçmişi sizinkiyle değiştirir; o dalı çekmiş başka bir kişi artık uyumsuz bir geçmişle kalır ve yaptığı işler çakışabilir. Bu yüzden zorla push paylaşılan dallarda kaçınılması gereken bir işlemdir. Zorunluysa önce ekibe haber verin; mümkünse yalnızca kendinize ait bir özellik dalında, başkaları kullanmıyorken uygulayın.

Gizli bilgi (parola, anahtar) içeren bir commit'i geri almak ise farklı bir durumdur: geçmişte durduğu sürece bilgi sızmış sayılır. Bu durumda geri almaktan önce ilgili bilgiyi geçersiz kılmak gerekir.

Sık hatalar ve nasıl önlenir?

En sık hata, paylaşılmış bir dalda reset ile zorla push yapmaktır. Doğrusu, paylaşılmış geçmişte revert kullanmaktır.

İkinci hata, hard reset'i fark etmeden çalıştırmaktır. Doğrusu, önce git status ve git log ile mevcut durumu görmek, emin değilseniz soft ya da mixed ile başlamaktır; bu kipler çalışma dizinindeki değişikliklerinizi korur.

Üçüncü hata, restore ile reset'i karıştırmaktır. Restore dosya içeriğini değiştirir, reset ise commit işaretçisini; ihtiyacınız tek dosyaysa restore yeterlidir.

Dördüncü hata, merge commit'ini -m parametresi olmadan geri almaya çalışmaktır. Git hangi tarafın ana hat olduğunu bilemeyeceği için işlemi reddeder.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Geri alma komutları, bir ekipte aynı depo üzerinde çalışan geliştiriciler için gündelik güvenlik ağıdır. Hangi komutun ne zaman güvenli olduğunu bilmek, paylaşılan dalları bozmadan hata düzeltmeyi sağlar.

GİT ve GITHUB Uzmanlığı Eğitimi, branch yönetimi, merge işlemleri ve ileri düzey Git tekniklerini bir arada ele alır; geri alma kararlarının dallanma ve işbirliği bağlamında nasıl verildiğini bu çerçevede çalışabilirsiniz.