--- title: 'Hazırlıktan Çıkarma ve Dosya Geri Yükleme' source: 'https://academia.sh/tr/kurslar/surum-kontrolune-giris/hazirliktan-cikarma-ve-dosya-geri-yukleme' course: 'Sürüm Kontrolüne Giriş' language: tr updated: '2026-08-17T18:10:48+00:00' license: 'CC BY-SA 4.0' --- # Hazırlıktan Çıkarma ve Dosya Geri Yükleme Hazırlık alanındaki kaydın ve çalışma dizinindeki içeriğin ayrı ayrı geri alınması; kaynak seçimi ve hangi durumların kurtarılabilir olduğu. 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: ```bash ./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: ```bash 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 ```bash 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: ```bash 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 ```bash git restore ara.sh git status --short ``` ``` M terimler.txt ``` ```bash ./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: ```bash 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: ```bash 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 ` | Çalışma dizini | | `git restore --staged ` | Hazırlık alanı | | `git restore --staged --worktree ` | 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: ```bash 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: ```bash 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: ```bash 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.