--- title: 'Sıfırlama Kipleri' source: 'https://academia.sh/tr/kurslar/surum-kontrolune-giris/sifirlama-kipleri' course: 'Sürüm Kontrolüne Giriş' language: tr updated: '2026-08-17T18:10:48+00:00' license: 'CC BY-SA 4.0' --- # Sıfırlama Kipleri Dal ucunun geriye taşınması; `--soft`, `--mixed` ve `--hard` kiplerinin üç bölgeye etkisi, kaybolan içerik ve başvuru günlüğüyle kurtarma. Değiştirme, dal ucunu aynı öncüle bağlanan yeni bir işlemeye taşıyordu. **Sıfırlama (reset)**, dal ucunu tarihçede daha geriye taşır: bir ya da daha çok işleme, dalın erişilebilir geçmişinden düşer. Sıfırlamanın üç kipi vardır ve aralarındaki fark, hangi bölgelerin etkilendiğidir. Bu ders üç kipi aynı hata üzerinde tek tek uygular. ## Hata Terim listesi abecesel sıralanmak istenir ve genel amaçlı bir sıralama aracına verilir. Sonuç: ``` ağaç | tree bağlı liste | linked list dizi | array karma tablosu | hash table kuyruk | queue küme | set yığıt | stack çizge | graph öbek | heap ``` Sıra yanlıştır. "çizge" ve "öbek" listenin sonuna düşmüş, "küme" ise "kuyruk"tan sonra gelmiştir. Nedeni, sıralamanın Türkçe abeceye göre değil bayt değerlerine göre yapılmasıdır: Bilgisayarlar Nasıl Çalışır kursunda görüldüğü gibi, ASCII aralığı dışındaki harfler UTF-8'de birden çok baytla kodlanır ve ilk baytları tüm ASCII harflerinden büyüktür. Doğru sıra, dile duyarlı bir karşılaştırma düzeni gerektirir. Hata fark edilmeden işlenir: ```bash git commit -m "Terim listesini abecesel sırala" ``` ``` [main d85a348] Terim listesini abecesel sırala 1 file changed, 5 insertions(+), 5 deletions(-) ``` ## Sıfırlama Ne Yapar Sıfırlama üç adımdan oluşur ve kip, adımların kaçının uygulanacağını belirler: 1. **Dal ucunu taşı.** Her kipte yapılır. 2. **Hazırlık alanını hedefe eşitle.** `--soft` dışında yapılır. 3. **Çalışma dizinini hedefe eşitle.** Yalnızca `--hard` ile yapılır. Birinci adım tarihçeye, ikinci ve üçüncü adımlar içeriğe dokunur. ## `--soft` ```bash git reset --soft HEAD~1 git log --oneline -n 1 ``` ``` 18600c5 README'ye kullanım bölümü ekle ``` İşleme tarihçeden düştü. İçeriğe ne oldu? ```bash git status --short ``` ``` M terimler.txt ``` Değişiklik hazırlık alanında duruyor. Yalnızca birinci adım uygulandı: dal ucu geriye taşındı, hazırlık alanı ve çalışma dizini olduğu gibi bırakıldı. Sonuç, "işleme hiç yazılmamış ama içerik işlenmeye hazır" durumudur. ```bash git diff --staged --stat ``` ``` terimler.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) ``` Bu kip, son işlemenin kapsamını yeniden düzenlemek için kullanılır: işleme geri alınır, içerik istenen biçimde bölünür ve yeniden işlenir. ## `--mixed` İşleme yeniden yazılıp bu kez varsayılan kiple sıfırlanır: ```bash git reset HEAD~1 ``` ``` Unstaged changes after reset: M terimler.txt ``` ```bash git status --short ``` ``` M terimler.txt ``` İşaret ikinci sütuna geçti: içerik artık hazırlık alanında değil, yalnızca çalışma dizininde. Birinci ve ikinci adım uygulandı. `--mixed` yazılmasa da varsayılan kip budur. Bu kip, hem işlemeyi hem de hazırlık alanındaki seçimi geri alır; hangi dosyaların birlikte işleneceğine baştan karar vermek istendiğinde kullanılır. ## `--hard` ```bash git reset --hard HEAD~1 ``` ``` HEAD is now at 18600c5 README'ye kullanım bölümü ekle ``` ```bash git status --short ``` Çıktı boştur. Terim listesi de eski hâline dönmüştür: sıralama tümüyle geri alınmıştır. Üç adım da uygulandı. Bu kip **yıkıcıdır** ve iki ayrı içeriği götürür: sıfırlanan işlemelerin içeriğini ve o sırada çalışma dizininde bulunan, işlenmemiş bütün düzenlemeleri. Birincisi başvuru günlüğünden geri getirilebilir; ikincisi getirilemez. `git reset --hard` çalıştırmadan önce `git status` çıktısına bakmak, bu ikinci kaybı önlemenin tek yoludur. ## Üç Kipin Karşılaştırması | Kip | Dal ucu | Hazırlık alanı | Çalışma dizini | Değişiklik nerede kalır | |---|---|---|---|---| | `--soft` | Taşınır | Dokunulmaz | Dokunulmaz | Hazırlık alanında | | `--mixed` | Taşınır | Eşitlenir | Dokunulmaz | Çalışma dizininde | | `--hard` | Taşınır | Eşitlenir | Eşitlenir | Hiçbir yerde | Tablo tek bir cümleye indirgenebilir: kip sertleştikçe geri alma daha derine iner. Seçim, işlemenin içeriğinin korunup korunmayacağına göre yapılır. ## Kurtarma Sıfırlanan işleme nesne veritabanında durur ve başvuru günlüğünden bulunabilir: ```bash git reflog -n 6 ``` ``` 18600c5 HEAD@{0}: reset: moving to HEAD~1 d85a348 HEAD@{1}: commit: Terim listesini abecesel sırala 18600c5 HEAD@{2}: reset: moving to HEAD~1 d85a348 HEAD@{3}: commit: Terim listesini abecesel sırala 18600c5 HEAD@{4}: reset: moving to HEAD~1 d85a348 HEAD@{5}: commit: Terim listesini abecesel sırala ``` Günlük, üç kipin denendiği sırayı olduğu gibi kaydetmiştir. İşleme kimliğinin her seferinde `d85a348` çıkması rastlantı değildir: içerik, mesaj, yazar ve tarih aynı olduğu sürece kimlik de aynıdır. İçerik adresli depolamanın doğrudan sonucudur. Dal ucu istenen kimliğe geri taşınır: ```bash git reset --hard d85a348 ``` ``` HEAD is now at d85a348 Terim listesini abecesel sırala ``` İşleme tarihçeye döndü. Bu örnekte sıralama gerçekten yanlış olduğu için son karar onu düşürmektir: ```bash git reset --hard HEAD~1 ``` ``` HEAD is now at 18600c5 README'ye kullanım bölümü ekle ``` ## Yol Verilen Biçim `git reset` komutuna bir yol verildiğinde davranış tümüyle değişir: dal ucu taşınmaz, yalnızca o yolun hazırlık alanındaki kaydı hedefteki hâline döndürülür. ```bash git add terimler.txt git status --short ``` ``` M terimler.txt ``` ```bash git reset terimler.txt ``` ``` Unstaged changes after reset: M terimler.txt ``` ```bash git status --short ``` ``` M terimler.txt ``` Bu, önceki derste `git restore --staged` ile yapılan işin eski yazımıdır. Aynı komut adının yol verildiğinde ve verilmediğinde farklı işler yapması, `git restore` komutunun neden ayrı adlandırıldığını açıklar. ## `ORIG_HEAD` Sıfırlama, dal ucunu taşımadan önce eski değeri `ORIG_HEAD` adlı bir dosyaya yazar: ```bash cat .git/ORIG_HEAD ``` ``` 2aff8c57391d20c90c05be4eb3f9a385fd140cf2 ``` Bu ad bir başvuru gibi kullanılabilir; yanlışlıkla yapılan bir sıfırlamayı geri almanın en kısa yolu, başvuru günlüğünü okumadan `ORIG_HEAD` hedefine dönmektir: ```bash git reset --hard ORIG_HEAD ``` Dosya yalnızca son işlemi kaydeder; art arda yapılan sıfırlamalarda üzerine yazılır. Daha geriye gitmek için başvuru günlüğü gerekir. ## Sıfırlama ile Dosya Geri Yükleme Farkı İki komut karıştırılır çünkü ikisi de "geri alma" olarak adlandırılır. Ayrım nettir: - `git restore` **yol** üzerinde çalışır; tarihçeye dokunmaz. - `git reset` **başvuru** üzerinde çalışır; dal ucunu taşır. Bir dosyayı eski hâline döndürmek istiyorsanız `git restore`, bir işlemeyi tarihçeden düşürmek istiyorsanız `git reset` kullanılır. Sıfırlamanın kendisi de paylaşılmış tarihçede sorunludur: dal ucunu geriye taşımak, o işlemeleri almış kopyalarla uyumsuzluk yaratır. Önceki dersteki kural burada da geçerlidir — paylaşılmış tarihçe geriye alınmaz. ## Özet - Sıfırlama dal ucunu taşır; kip, hazırlık alanı ile çalışma dizininin de eşitlenip eşitlenmeyeceğini belirler. - `--soft` içeriği hazırlık alanında, `--mixed` çalışma dizininde bırakır; `--hard` her ikisini de hedefe eşitler. - `--hard`, işlenmemiş düzenlemeleri geri getirilemez biçimde siler. - Sıfırlanan işlemeler nesne veritabanında kalır; başvuru günlüğünden bulunup geri getirilebilir. - Aynı içerik, mesaj, yazar ve tarih her zaman aynı işleme kimliğini üretir. ## Sonraki Adım Sıfırlama ve değiştirme, tarihçeyi yeniden yazarak çalışıyor ve bu nedenle paylaşılmış işlemelerde kullanılamıyor. Peki paylaşılmış bir işleme hatalıysa ne yapılır? Sonraki ders, tarihçeyi bozmadan bir işlemenin etkisini tersine çeviren aracı — devirmeyi — ele alacak.