7.7 Git Tools - Reset Komutunun Gizemleri

Git’in üç farklı çalışma ağacının içeriğini yöneten bir içerik yöneticisi olduğunu hayal etmek, reset ve checkout komutlarını anlamayı kolaylaştırır. Burada "ağaç" derken gerçekten "dosya dizinini" kastediyoruz, bir veri yapısı olan ağacı (tree) değil. (Birkaç durumda, dizin tam olarak bir ağaç gibi davranmaz, ancak şu anda amacımız için bu şekilde düşünmek daha kolaydır.)

Git sistemi normal işleyişinde üç ağacı yönetir ve onları değiştirir:

Git’in tipik iş akışı, bu üç ağacı manipüle ederek projenizin ardışık olarak daha gelişmiş durumlarının pozlarını kaydetmektir.

Hadi bu süreci görselleştirelim: Diyelim ki tek bir dosyanın bulunduğu yeni bir dizine giriyorsunuz. Mavi renkte göstereceğimiz bu dosyayı v1 olarak adlandıralım. Şimdi git init komutunu çalıştırıyoruz: bu daha doğmamış master dalına işaret eden bir HEAD referansı ile bir Git reposu oluşturacak.

Bu noktada, sadece çalışma dizini ağacında içerik bulunmaktadır.

Şimdi bu dosyayı katkı olarak işlemek istiyoruz, bu yüzden git add komutunu kullanarak çalışma dizinindeki içeriği alıp indekse (izlem) kopyalarız.

Ardından git commit komutunu çalıştırırız: bu komut dizinin içeriğini alır ve onu kalıcı bir poz olarak kaydeder, o poza işaret eden bir katkı nesnesi oluşturur ve master 'ı bu katkıya işaret edecek şekilde günceller.

git status komutunu çalıştırırsak, henüz değişiklik yapmadığımız için, her üç ağacın da aynı olduğunu göreceğiz.

Şimdi dosyayı değiştirip, katkı olarak işlemek istiyoruz. Aynı süreci geçireceğiz; önce çalışma dizininde dosyayı değiştireceğiz. Dosyanın bu sürümüne v2 diyelim ve onu kırmızı renkle gösterelim.

Şu anda git status komutunu çalıştırırsak, dosyayı kırmızı renkte ve ``Changes not staged for commit`` açıklamasıyla göreceğiz; çünkü bu giriş indeks ile çalışma dizini arasındaki bir farklılık olarak görünecektir. Daha sonra bu dosya üzerinde git add komutunu çalıştırarak, onu indekse ekliyoruz.

Bu noktada, git status komutunu çalıştırırsak, dosyayı yeşil renkte "Yapılacak katkılar" altında göreceğiz; çünkü indeks ile uç farklıdır - yani önerilen sıradaki katkımız, işlenmiş son katkımızdan farklıdır. Son olarak, katkılama işlemini tamamlamak için git commit komutunu çalıştırıyoruz.

Şimdi git status komutunu çalıştırdığımızda, tekrar tüm ağaçlar aynı olduğu için herhangi bir çıktı almayacağız.

Dallar arasında geçiş yapmak veya kopyalamak benzer bir süreçten geçer. Yeni bir dala geçiş yapmak, HEAD işaretçisini yeni dal referansını gösterecek şekilde değiştirir, indeks içeriğini o katkının pozuyla doldurur ve son olarak indeks içeriğini çalışma dizinine kopyalar.

reset komutu, bu bağlamda görüldüğünde daha mantıklı hale gelir.

Bu örnekleri daha iyi anlamak için, diyelim ki file.txt dosyasını tekrar değiştirdik ve üçüncü kez katkıladık. Şimdi geçmişimiz şöyle görünüyor:

Şimdi, reset çağrıldığında tam olarak ne yaptığını adım adım görelim. Basit ve öngörülebilir bir şekilde üç ağacı doğrudan manipüle eder. Üç temel işlem yapar.

Bu, reset 'in temel formundaki davranışını kapsar, ancak isterseniz bir dizin de belirtebilirsiniz. Bir dizin belirtirseniz, reset adım 1’i atlar ve geri kalan işlemleri belirli bir dosya veya dosya kümesiyle sınırlar. Bu aslında bir bakıma mantıklıdır - HEAD sadece bir işaretçidir ve onu aynı anda bir katkının bir kısmına ve başka bir katkının başka bir kısmına doğrultamazsınız. Ancak indeks ve çalışma dizini kısmen güncellenebilir, bu nedenle reset yoluna 2. ve 3. adımlarla devam eder.

Öyleyse, git reset file.txt komutunu çalıştıralım. Bu form (bir katkı SHA-1 karması, bir dal ya da --soft veya --hard gibi bir bayrak belirtmediğiniz için) git reset --mixed HEAD file.txt söz diziminin kısaltmasıdır ve şunları yapar:

Yani temelde file.txt dosyasını HEAD’ten indekse kopyalar.

Bu, pratikte dosyanın izlemden çıkarılması etkisine sahiptir. Bu komutun diyagramına bakarsak ve git add komutunun ne yaptığını düşünürsek, tam olarak zıt olduklarını görürüz.

Bu nedenle, git status komutunun çıktısı, bir dosyayı izlemden çıkarmak için bunu çalıştırmanızı önerir. (Daha fazla bilgi için: İzleme Alınmış Dosyayı izlemden Çıkarmak)

Git’in "veriyi HEAD’den çek" dediğimizi varsaymasını önlemek için belirli bir katkıyı belirtebiliriz. Yoksa, sadece git reset eb43bf file.txt gibi bir şey çalıştırmak yeterdi.

Bununla, etkili bir şekilde (aslında tüm bu adımları geçmeden) dosyanın içeriğini çalışma dizinindeki v1'e geri döndürdük, üzerine git add çalıştırdık, ardından tekrar v3'e geri döndürdük. Şimdi git commit komutunu çalıştırırsak, aslında çalışma dizinimizde hiç sahip olmadığımız halde, dosyayı tekrar v1'e geri döndüren bir değişikliği kaydedecektir.

Ayrıca, aynı git add gibi, reset komutu da içeriği izlemden parça parça çıkarmak için --patch seçeneğini kabul eder. Bu şekilde içeriği seçici olarak izlemden çıkarabilir veya geri alabilirsiniz.

Bu yeni keşfedilen güçle ilginç bir şeyin nasıl yapılacağına bakalım: katkıları sıkıştırmak.

Diyelim ki ``oops.``, ``WIP`` ve ``bu dosyayı unuttum`` gibi mesajlar içeren bir dizi katkınız var. Bunları hızlı ve kolay bir şekilde tek bir işleme dönüştürmek ve gerçekten zeki görünmenizi sağlamak için reset komutunu kullanabilirsiniz. Sıkıştırma (Katkıları Sıkıştırmak) bunu yapmanın başka bir yoludur, ancak bu örnekte reset 'i kullanmak daha basittir.

Diyelim ki, ilk katkının bir dosyaya sahip olduğu, ikinci katkının yeni bir dosya ekleyip ilkini değiştirdiği ve üçüncü katkının ilk dosyayı yeniden değiştirdiği bir projeniz var. İkinci katkı devam eden bir çalışmaydı ve siz onu ortadan kaldırmak istiyorsunuz.

HEAD dalını daha eski bir katkıya (saklamak istediğiniz en son katkıya) geri taşımak için git reset --soft HEAD~2 komutunu çalıştırabilirsiniz:

Ve sonra tekrar "git commit" komutunu çalıştırın:

Artık itme yapabileceğiniz geçmişinizin, birinci katkının file-a.txt dosyasının v1 sürümüne sahip olduğunu ve ikinci bir katkının hem file-a.txt 'yi v3 sürümüne değiştirdiğini hem de file-b.txt 'yi eklediğini görebilirsiniz. Dosyanın v2 sürümüyle yapılan kayıt ise artık geçmişte yer almaz.

Son olarak, checkout ve reset arasındaki farkı merak ediyor olabilirsiniz. Reset gibi, checkout da üç ağacı manipüle eder ama komuta bir dosya dizini belirtip belirtmemenize bağlı olarak biraz farklılık gösterir.

Artık reset komutunu genel olarak anladınız ve daha rahat hissediyorsunuzdur. Ancak yine de tam olarak checkout komutundan nasıl farklı olduğu konusunda kafanızda biraz karışıklık kalmış olabilir. Zaten farklı kullanımların tüm kurallarını ezbere bilmek de imkansızdır.

İşte hangi komutların hangi ağaçları etkilediğine dair bir hatırlatma notu. HEAD sütunu, komutun HEAD’in işaret ettiği referansı (dalı) taşıyıp taşımadığını belirtir; ve eğer HEAD’i taşıyorsa HEAD, aksi takdirde REF okunur. "Çalışma Ağacı Güvende mi?" sütununa özellikle dikkat edin — eğer Hayır yazıyorsa, bu komutu çalıştırmadan önce bir kez daha düşünün.