Hazırlıktan Çıkarma ve Dosya Geri Yükleme

Temel döngü tek yönlü anlatıldı: değişiklik yapılır, hazırlık alanına alınır, işlenir. Bu konu ters yönü ele alıyor. İlk ders en dar kapsamlı iki işlemi tanımlar; ikisi de tarihçeye dokunmaz, yalnızca çalışma dizinini ve hazırlık alanını etkiler.

Ayrımı baştan kurmak gerekir, çünkü iki işlem farklı şeyleri geri alır ve birinin bedeli diğerinden ağırdır.

İki Ayrı Geri Alma

İşlem	Etkilediği bölge	Kaynak	Kaybolan
Hazırlıktan çıkarma	Hazırlık alanı	Son işleme	Yok
Dosya geri yükleme	Çalışma dizini	Hazırlık alanı ya da bir işleme	Kaydedilmemiş düzenlemeler

Birinci işlem geri alınabilir: hazırlıktan çıkarılan içerik çalışma dizininde durmaya devam eder. İkinci işlem geri alınamaz — çalışma dizinindeki düzenleme hiçbir yerde saklanmadıysa üzerine yazıldığında gider.

Hata

Terim listesine iki terim eklenirken arama betiğinde de bir düzenleme yapılır: grep çağrısına -x seçeneği eklenir. Bu seçenek eşleşmenin tüm satırı kapsamasını zorunlu kılar ve betiği bozar:

./ara.sh yığıt

eşleşme yok: yığıt

Terim listede bulunduğu hâlde bulunamıyor: -x, “yığıt” örüntüsünün yığıt | stack satırının tamamına eşit olmasını istiyor. Hata fark edilmeden iki değişiklik birlikte hazırlık alanına alınır:

git add .
git status --short

M  ara.sh
M  terimler.txt

Terim eklemesi tutulmalı, betikteki düzenleme geri alınmalıdır.

Hazırlıktan Çıkarma

git restore --staged ara.sh
git status --short

 M ara.sh
M  terimler.txt

ara.sh işareti birinci sütundan ikinci sütuna geçti: dosya artık hazırlık alanında değil, yalnızca çalışma dizininde değişik. Komut hazırlık alanındaki girdiyi son işlemedeki hâline döndürdü; çalışma dizinine dokunmadı.

Bunu doğrulamak için fark alınır:

git diff

diff --git a/ara.sh b/ara.sh
index 582ddde..fd7e235 100755
--- a/ara.sh
+++ b/ara.sh
@@ -6,7 +6,7 @@ if [ $# -ne 1 ]; then
     exit 1
 fi
 
-if ! grep -i -- "$1" terimler.txt; then
+if ! grep -ix -- "$1" terimler.txt; then
     echo "eşleşme yok: $1" >&2
     exit 2
 fi

Düzenleme yerinde duruyor. Bu noktada iki seçenek vardır: düzenlemeyi elle düzeltmek ya da tümüyle geri almak.

Çalışma Dizinini Geri Yükleme

git restore ara.sh
git status --short

M  terimler.txt

./ara.sh yığıt

yığıt | stack

Betik yeniden çalışıyor. git restore, dosyayı hazırlık alanındaki hâline döndürdü; hazırlık alanı da son işlemeyle aynı olduğu için sonuç, dosyanın son işlemedeki hâlidir.

Bu komut yıkıcıdır. Geri alınan düzenleme hiçbir yerde saklanmamıştı; ne nesne veritabanında ne de hazırlık alanında bir kaydı vardı. Komut çalıştıktan sonra o metin geri getirilemez. Kural olarak, geri alınacak düzenlemenin gerçekten istenmediğinden emin olmadan çalıştırılmamalı; kararsızlık varsa değişiklik önce hazırlık alanına alınmalı ya da zulaya konmalıdır. Zula, bu konunun beşinci dersinin konusudur.

Kalan değişiklik işlenir:

git commit -m "Öbek ve dizi terimlerini ekle"

[main bfe57d3] Öbek ve dizi terimlerini ekle
 1 file changed, 2 insertions(+)

Kaynağı Seçmek

Varsayılan olarak git restore kaynağı hazırlık alanıdır. --source seçeneği başka bir işlemeyi kaynak yapar:

git restore --source=HEAD~1 terimler.txt
git diff --stat

 terimler.txt | 2 --
 1 file changed, 2 deletions(-)

Dosya bir önceki işlemedeki hâline döndü; iki satır eksildi. Bu, geçmişteki bir sürümü inceleme ya da tek bir dosyayı geri getirme yoludur. Değişiklik yalnızca çalışma dizinindedir; tarihçe olduğu gibi durur ve git restore terimler.txt ile son duruma dönülür.

Komutun etkilediği bölgeler açıkça seçilebilir:

Yazım	Etkilenen
git restore <yol>	Çalışma dizini
git restore --staged <yol>	Hazırlık alanı
git restore --staged --worktree <yol>	Her ikisi

Üçüncü satır, bir dosyayı tümüyle son işlemedeki hâline döndürür.

Silinen Dosyayı Geri Getirmek

Silme de bir değişikliktir ve aynı araçla geri alınır. Terim listesi yanlışlıkla silinirse:

git status --short

 D terimler.txt

D işareti ikinci sütunda: dosya çalışma dizininden kaldırılmış ama hazırlık alanındaki kaydı duruyor. Kayıt bir blob kimliği taşıdığına göre içerik nesne veritabanındadır:

git restore terimler.txt
git status --short

İkinci komut hiçbir şey yazmaz; dosya geri gelmiştir. Silme hazırlık alanına da alınmışsa (D birinci sütunda görünüyorsa) önce hazırlıktan çıkarmak, sonra geri yüklemek gerekir; --staged --worktree ikisini tek komutta yapar.

Bu, önceki bölümdeki ölçütün doğrudan sonucudur: silinen dosyanın içeriği izleniyordu, dolayısıyla nesne veritabanındaydı. İzlenmeyen bir dosya silindiğinde geri getirilemez.

Eski Yazımlar

Aynı işler daha eski komutlarla da yapılabilir ve belgelerde bu yazımlara sık rastlanır:

git reset HEAD terimler.txt      # hazırlıktan çıkarma
git checkout -- terimler.txt     # çalışma dizinini geri yükleme

Birinci komut şu bilgilendirmeyi yazar:

Unstaged changes after reset:
M	terimler.txt

İki eski yazımın sorunu, komutların aşırı yüklenmiş olmasıdır: git reset aynı zamanda tarihçeyi geriye alan, git checkout aynı zamanda dallar arasında geçiş yapan komuttur. Aynı adın çok farklı sonuçlar doğurması, hangi işlemin yapıldığını komuttan okumayı zorlaştırır. git restore ve git switch komutları bu ayrımı adlandırmak için tanımlanmıştır. Eski yazımlar geçerliliğini korur; bu kursta yeni adlar kullanılacaktır.

Neyin Kurtarılabildiği

Geri alma araçlarının sınırı tek bir ölçüte indirgenir: içerik nesne veritabanına yazıldı mı?

Durum	Nesne veritabanında	Kurtarılabilir mi
İşlenmiş içerik	Evet	Evet
Hazırlık alanına alınmış içerik	Evet (blob olarak)	Evet
Yalnızca çalışma dizinindeki düzenleme	Hayır	Hayır
İzlenmeyen dosya	Hayır	Hayır

İkinci satır beklenmedik olabilir: git add çalıştırıldığı anda içerik blob olarak yazılır ve işleme yapılmasa bile veritabanında kalır. Hazırlıktan çıkarılan ve sonra üzerine yazılan bir içerik bile, kimliği bilindiği sürece git cat-file ile okunabilir. Buna karşılık hiç hazırlığa alınmamış bir düzenlemenin hiçbir izi yoktur.

Pratik sonuç şudur: uzun süre üzerinde çalışılan bir değişiklik, ara ara hazırlık alanına alınırsa yıkıcı bir komuta karşı korunmuş olur. Bu, hazırlık alanının işlemeye hazırlık dışında ikinci bir işlevidir.

Özet

• Hazırlıktan çıkarma hazırlık alanını, dosya geri yükleme çalışma dizinini etkiler.
• git restore --staged kaydı son işlemedeki hâline döndürür ve veri kaybettirmez.
• git restore çalışma dizinindeki düzenlemeyi yıkıcı biçimde geri alır.
• --source ile kaynak bir işleme seçilebilir; --staged --worktree her iki bölgeyi birden geri yükler.
• Kurtarılabilirliğin ölçütü, içeriğin nesne veritabanına yazılmış olmasıdır; hazırlığa alma bu güvenceyi sağlar.

Sonraki Adım

Bu araçlar henüz işlenmemiş değişiklikleri geri alıyor. Yazılmış bir işlemede eksik ya da hata varsa ne yapılır? Sonraki ders son işlemenin değiştirilmesini, bu işlemin neden yeni bir nesne ürettiğini ve hangi durumlarda kullanılmaması gerektiğini ele alacak.