Git
Chapters ▾ 2nd Edition

2.4 Git Basics - Değişiklikleri Geri Alma

Değişiklikleri Geri Alma

Herhangi bir aşamada bir şeyi geri almak isteyebilirsiniz. Burada, yaptığınız değişiklikleri geri almak için kullanabileceğiniz birkaç temel aracı inceleyeceğiz. Bu geri alma işlemlerinin bazılarını her istediğinizde iptal ederek (bu geri alma işlemi öncesi) eski duruma geri "dönemeyebileceğiniz" için, dikkatli olmalısınız. Bu, Git’te yanlış yaparsanız bazı çalışmalarınızı kaybedebileceğiniz birkaç özel durumdan biridir.

Yaygın geri alma ihtiyaçlarından biri, bazı dosyaları eklemeyi unuttup katkınızı çok erken işlediğinizde veya yanlış bir katkı mesajı yazdığınızda ortaya çıkar. Bir katkıyı yeniden işlemek istiyorsanız, unuttuğunuz ek değişiklikleri yapın, bunları izlem alın ve --amend seçeneğini kullanarak yeniden katkılayın:

$ git commit --amend

Bu komut izlem alanınızı alır ve katkılamak için kullanır. Son katkınızdan beri hiçbir değişiklik yapmadıysanız (örneğin, bu komutu en son katkınızdan hemen sonra çalıştırdıysanız), pozunuz tamamen aynı olacak ve değiştireceğiniz tek şey katkı mesajınız olacaktır.

Bunu yaptığınızda aynı "katkı mesajı düzenleyicisi" aynı katkı mesajıyla devreye girer. Mesajı her zamanki gibi düzenleyebilirsiniz, ancak bu sefer önceki katkı mesajınızın üzerine yazılır.

Örnek olarak, katkı yapar ve daha sonra bu işleme eklemek istediğiniz dosyadaki değişiklikleri izleme almayı unuttuğunuzu fark ederseniz, şunun gibi bir şey yapabilirsiniz:

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

Bu işlemin sonucunda, ikinci katkınızın ilk katkınızın yerini aldığı tek bir katkı elde edersiniz.

Şunu anlamanız özellikle önemli: Eğer (amend komutuyla) son katkınızı onarırsanız; aslında son katkınızı düzeltmekten ziyade, eski katkınızı ortadan kaldırıp, onun yerine yeni bir katkı işlemektesiniz. Sanki önceki katkı hiç gerçekleşmemiş ve repo geçmişinizde görünmeyecekmiş gibi.

Önceki katkıları değiştirmenin asıl önemi, repo geçmişinizi ``Hata, bir dosya eklemeyi unuttum`` veya ``Lanet olsun, son işlemdeki bir yazım hatasını düzelttim`` şeklinde gereksiz katkı mesajlarıyla doldurmadan, son işleminizde küçük iyileştirmeler yapmaktır.

İzleme Alınmış Dosyayı izlemden Çıkarmak

Sonraki iki bölümde izlem alanınız ve çalışma dizini değişiklikleriyle nasıl çalışılacağı gösterilmektedir. İşin güzel yanı, bu iki alanın durumunu tanımlamak için kullandığımız komutun aynı zamanda bu alanlarda yapılan değişiklikleri nasıl geri alacağımızı da bize söylemesidir. Örneğin, iki dosyayı değiştirdiğinizi ve bunları iki ayrı değişiklik olarak işlemek istediğinizi, ama yanlışlıkla git add * yazıp ikisini birden izleme aldığınızı varsayalım. İkisinden sadece birini nasıl izlemden çıkarabilirsiniz? git status komutu size bunu nasıl yapacağınızı zaten hatırlatmaktadır:

$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README
    modified:   CONTRIBUTING.md

``Changes to be committed`` metninin hemen altında, düzenlemeyi kaldırmak için git reset HEAD <file>... kullanın yazıyor. O halde, CONTRIBUTING.md dosyasını aşamadan çıkarmak için bu yönergeyi kullanalım:

$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M	CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Komut biraz garip ama neticede işe yarıyor. CONTRIBUTING.md dosyası değiştirildi ancak nihai durumda "stage"de (izlemde) değil.

git reset`in tehlikeli bir komut olabileceği doğrudur, özellikle de `--hard bayrağını kullanırsanız. Ancak yukarıda açıklanan senaryoda çalışma dizininizdeki dosyaya dokunulmaz, dolayısıyla nispeten güvenlidir.

Şimdilik bu sihirli çağrı, git reset komutu hakkında bilmeniz gereken tek şeydir. Reset Komutunun Gizemleri bölümünde reset'in ne yaptığı ve çok daha ilginç şeyler yapmak için bunda nasıl ustalaşılacağı hakkında çok daha fazla ayrıntıya gireceğiz.

Değiştirilmiş Dosyadaki Değişikliği Geri Alma

CONTRIBUTING.md dosyasındaki değişikliklerinizi saklamak istemediğinizi fark ederseniz ne yaparsınız? Yaptığınız değişiklikleri kolayca nasıl kaldırabilirsiniz veya en son katkınızdaki (veya başlangıçta kopyaladığınız ya da çalışma dizininize soktuğunuz) haline nasıl geri döndürebilirsiniz? Neyse ki, git status size bunu nasıl yapacağınızı da söyler. Son örnek çıktıda, "unstaged" alan şuna benzer:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Yaptığınız değişiklikleri nasıl iptal edeceğiniz oldukça açık bir şekilde anlatmaktadır. Hadi söyleneni yapalım:

$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Değişikliklerin geri alındığını görebilirsiniz.

git checkout -- <file> komutunun tehlikeli bir komut olduğunu anlamanız çok önemlidir. Bu dosyada yaptığınız tüm yerel değişiklikler kayboldu! Git, bu dosyayı en son kaydedilen sürümle değiştirdi. Kaydedilmemiş yerel değişiklikleri istemediğinizden kesinlikle emin olmadığınız sürece bu komutu asla kullanmayın!

Bu dosyada yaptığınız değişiklikleri korumak istiyorsanız ancak şimdilik yine de ondan kurtulmanız gerekiyorsa, Git Branching bölümünde saklama ve dallandırma işlemlerini ele alacağız. Bu işi yapmanın genellikle daha kullanışlı yolları olduğunu göreceksiniz.

Git’te committed durumda olan her şeyin neredeyse her zaman kurtarılabileceğini unutmayın. Hatta silinen dallardaki katkılar veya --amend komutuyla üzerini yeniden yazılan katkılar bile kurtarılabilir. (veri kurtarma için bkz. <ch10-git-internals#_data_recovery>>). Ancak, hiç katkı olarak işlemediğiniz bir şeyi tamamen kaybetmeniz de oldukça muhtemeldir.

scroll-to-top