10.7 Dahili Git Ögeleri - Bakım ve Veri Kurtarma

Arada sırada, Git otomatik olarak auto gc adlı bir komut çalıştırır. Çoğu zaman bu komut hiçbir şey yapmaz. Ancak, fazla sayıda gevşek nesne (paket dosyasında olmayan nesneler) veya fazla sayıda paket dosyası varsa, Git tam donanımlı bir git gc komutunu başlatır. gc çöp toplama (garbage collection) anlamına gelir ve bu komut birkaç şey yapar: tüm gevşek nesneleri toplayarak bunları paket dosyalarına yerleştirir, paket dosyalarını birleştirerek tek bir büyük paket dosyası haline getirir, birkaç ay öncesine dayanan ve hiçbir katkısına erişilemeyen nesneleri kaldırır.

Auto gc 'yi aşağıdaki gibi manuel olarak çalıştırabilirsiniz:

Tekrar belirtmek gerekirse, bu genellikle hiçbir şey yapmaz. Gerçek bir gc komutunu çalıştırmak için yaklaşık 7.000 gevşek nesneye veya 50’den fazla paket dosyasına ihtiyacınız vardır. Bu sınırları sırasıyla gc.auto ve gc.autopacklimit yapılandırma ayarları ile değiştirebilirsiniz.

gc 'nin yapacağı diğer bir şey de referanslarınızı tek bir dosyaya paketlemektir. Diyelim ki repo şu dalları ve etiketleri içeriyor:

git gc komutunu çalıştırırsanız, bu dosyalar artık refs dizininde bulunmaz. Git verimlilik açısından onları .git/packed-refs adlı, şu şekilde gözüken bir dosyaya taşır:

Bir referansı güncellerseniz Git bu dosyayı düzenlemez, bunun yerine refs/heads 'e yeni bir dosya yazar. Belirli bir referans için uygun SHA-1’i almak amacıyla Git, refs dizininde bu referansı kontrol eder ve ardından bir yedek olarak packed-refs dosyasını kontrol eder. Ancak, refs dizininde bir referans bulamazsanız, bu muhtemelen packed-refs dosyanızdadır.

Dosyanın ^ ile başlayan son satırına dikkat edin. Bu, doğrudan yukarıdaki etiketin açıklamalı bir etiket olduğu ve bu satırın açıklamalı etiketin işaret ettiği katkı olduğu anlamına gelir.

Git yolculuğunuzun bir noktasında, bir katkıyı kazara kaybedebilirsiniz. Bunu genellikle, üzerinde çalışma olan bir dalı zorla silip, sonunda dala yine ihtiyacınız olduğunu fark ettiğinizde yaşarsınız; veya bir dala sert sıfırlama yaparsınız, böylece ihtiyacınız olan bazı katkıları kaybetmiş olursunuz. Bu durum gerçekleşirse, katkıları nasıl geri alabilirsiniz?

İşte test repomdaki ana dalı bir önceki katkıya sert sıfırlayan ve sonra kaybolan katkıları kurtaran bir örnek: Önce, repomun şu anda nerede olduğunu gözden geçirelim:

Şimdi, master dalını ortadaki katkıya taşıyalım:

Etkili bir şekilde en üstteki iki katkıyı kaybettiniz ve bu katkılara erişilebilecek hiçbir dalınız yok. Bu katkıların SHA-1’ini bulmanız ve sonra ona işaret eden bir dal eklemeniz gerekiyor. Sorun, bu en son katkının SHA-1’ini bulmaktadır (neticede onu ezberlemediniz, değil mi)?

Genellikle, en hızlı yol git reflog adı verilen bir araç kullanmaktır. Çalışırken, Git HEAD’i her değiştirdiğinizde ne olduğunu sessizce kaydeder. Her bir katkı veya dal değiştirdiğinizde reflog güncellenir. Reflog ayrıca git update-ref komutu tarafından da güncellenir, bu da sadece SHA-1 değerini ref dosyalarınıza yazmak yerine onu kullanmanın başka bir nedenidir (Git Referansları bölümünde ele aldığımız gibi). Herhangi bir zamanda nerede olduğunuzu görmek için git reflog komutunu çalıştırarak geçmişinizi görebilirsiniz:

Burada kontrol ettiğimiz iki katkıyı görebiliriz, ancak burada pek fazla bilgi yok. Aynı bilgiyi çok daha kullanışlı bir şekilde görmek için git log -g komutunu çalıştırabiliriz, bu size reflog’unuz için normal bir günlük (log) çıktısı verecektir.

Görünüşe göre kaybettiğiniz katkı en alttaki katkıdır, bu yüzden onu o katkıya işaret eden yeni bir dal oluşturarak kurtarabilirsiniz. Örneğin, o katkıya (ab1afef) işaret eden recover-branch adında bir dal başlatabilirsiniz:

Harika – artık master dalınızın bulunduğu yerde olan recover-branch adında bir dalınız var, böylece ilk iki katkıya yeniden ulaşabilirsiniz. Şimdi, varsayalım ki kaybınız reflog’da değildi (recover-branch'i kaldırarak ve reflog’u silerek bu durumu canlandırabilirsiniz edebilirsiniz). Şimdi, ilk iki katkı hiçbir şey tarafından ulaşılamaz durumda:

Çünkü reflog verileri .git/logs/ dizininde saklanır, hiçbir etkin reflog’unuz yoktur. Bu noktada bu katkıyı nasıl kurtarabilirsiniz? Bir yol, veritabanınızı bütünlük açısından kontrol eden git fsck yardımcı programını kullanmaktır. Onu --full seçeneği ile çalıştırırsanız, başka bir nesne tarafından işaret edilmeyen tüm nesneleri size gösterir:

Bu durumda, eksik katkınızı ``dangling commit`` (sallantıdaki katkı) dizgesinden sonra görebilirsiniz. Aynı şekilde, o SHA-1’e işaret eden bir dal ekleyerek onu kurtarabilirsiniz.

Git’in harika birçok özelliği olsa da, sorunlara da neden olabilen bir özelligi: git clone komutunun projenin her dosyasının tüm sürümlerini de içermekte olan "tüm geçmişini" indirmesidir. Bu, hepsinin kaynak kodu olduğu durumlar için sorun değildir, çünkü Git bu veriyi etkili bir şekilde sıkıştırmak için yüksek derecede optimize edilmiştir. Ancak, projenizin geçmişinde herhangi bir noktada tek bir büyük dosya ekleyen biri olduğunda, her zaman için her klonun o büyük dosyayı indirmek zorunda kalacak olması - o dosya sonraki katkıda projeden kaldırılmış olsa bile - geçerli bir durumdur. Çünkü geçmişten erişilebilirdir ve her zaman orada olacaktır.

Bu, Subversion veya Perforce repolarını Git’e dönüştürürken büyük bir sorun olabilir. Bu sistemlerde tüm geçmişi indirmediğiniz için, bu tür bir eklemenin bazı sonuçları vardır. Başka bir sistemden bir içe aktarma yaptıysanız veya başka bir şekilde deponuzun beklenenden çok daha büyük olduğunu görürseniz, büyük nesneleri bulup kaldırmanın bir yolunu aşağıda bulabilirsiniz.

Dikkat: Bu teknik, katkı geçmişinize zarar vericidir. Büyük bir dosyanın referansını kaldırmak için değiştirirseniz, ilk ağacınızdan itibaren her katkı nesnesini yeniden yazacaktır. Bunu, bir içe aktarmadan hemen sonra ve henüz hiç kimse çalışmaya başlamamışken yaparsanız, sorunsuzdur. Aksi takdirde, tüm katkıda bulunanlara, çalışmalarını yeni katkılara dayandırmaları gerektiğini bildirmeniz gerekir.

Bu tekniği göstermek için, test repomuza büyük bir dosya ekleyecek, bir sonraki katkıda onu kaldıracak, ardından onu bulup repodan kalıcı olarak sileceğiz. İlk olarak, geçmişinize büyük bir nesne ekleyin:

Eyvah! Projenize devasa bir tarball eklemek istememiştiniz. Onu kaldırmak daha iyi olur:

Şimdi (gc komutuyla) veritabanınızı temizleyin ve kullandığınız alanı görün:

Kullandığınız alanı hızlı bir şekilde görmek için count-objects komutunu çalıştırabilirsiniz:

size-pack girişi, paket dosyalarınızın kilobayt cinsinden boyutudur, bu yüzden neredeyse 5MB kullanıyorsunuz. Son katkıdan önce yaklaşık 2K kullanıyordunuz: açıkçası, dosyayı önceki katkıdan kaldırmak onu geçmişinizden kaldırmadı. Bu repoyu kopyalayan herkes, bu küçük projeyi almak için 5MB’lik tümünü kopyalamak zorunda kalacak, çünkü yanlışlıkla büyük bir dosya eklediniz. Hadi onu kaldıralım.

İlk olarak, onu bulmanız gerekiyor. Bu durumda, zaten hangi dosyanın olduğunu biliyorsunuz. Ancak öyle olmadığını varsayalım; bu kadar çok alanı alan dosyayı veya dosyaları nasıl tanımlarsınız? git gc komutunu çalıştırırsanız, tüm nesneler bir paket dosyasında bulunur; büyük nesneleri tanımlamak için git verify-pack adlı başka bir işleme komutunu çalıştırabilir ve çıktıdaki üçüncü alana göre sıralayabilirsiniz, işte bu dosya boyutudur. Ayrıca, yalnızca en büyük birkaç dosyaya ilgilendiğiniz için çıktıyı tail komutuyla borudan (pipe) geçirebilirsiniz:

Büyük nesne en alttadır: 5MB. Bu dosyanın ne olduğunu bulmak için, kısa bir süre önce Belirli Bir Katkı Mesajı Formatını Zorunlu Hale Getirme bölümünde kullandığınız rev-list komutunu kullanacaksınız. rev-list'e --objects parametresini ilettiğinizde, tüm katkı SHA-1’leri ve bunlarla ilişkilendirilmiş dosya yollarıyla birlikte blok SHA-1’lerini listeler. Bunu blob’un adını bulmak için kullanabilirsiniz:

Şimdi, bu dosyayı geçmişinizdeki tüm ağaçlardan kaldırmanız gerekiyor. Bu dosyayı değiştiren tüm katkıları kolayca görebilirsiniz:

7b30847 'den sonraki tüm katkıları bu dosyayı tamamen Git geçmişinizden kaldırmak için yeniden yazmalısınız. Bunu yapmak için, Geçmişi Yeniden Yazma bölümünde kullandığınız filter-branch komutunu kullanırsınız:

--index-filter seçeneği, Geçmişi Yeniden Yazma bölümünde kullanılan --tree-filter seçeneğine benzer, ancak her seferinde diske çıkarılan dosyaları değiştiren bir komut yerine, indeksinizi veya dizin belirtmenizi sağlar.

rm dosya gibi belirli bir dosyayı kaldırmak yerine, onu git rm --cached ile kaldırmalısınız; bu onu dizinden değil, indeksten kaldırır. Bunu bu şekilde yapmamızın nedeni hızdır; çünkü Git, filtrelerinizi çalıştırmadan önce her revizyonu diske çıkarmak zorunda kalmadığı için, işlem çok daha hızlı olabilir. Aynı görevi --tree-filter ile de gerçekleştirebilirsiniz. git rm 'nin --ignore-unmatch seçeneği, kaldırmaya çalıştığınız desen orada olmadığında hata vermemesini sağlar. Son olarak, bu sorunun başladığı yere yani 7b30847 katkısından başlayarak yalnızca geçmişinizi yeniden yazmasını istersiniz, aksi takdirde işlem başlangıçtan başlayacak ve gereksiz yere daha uzun sürecektir.

Geçmişiniz artık o dosyaya bir referans içermiyor. Yine de reflog’unuz ve filter-branch yaptığınızda Git’in eklediği yeni bir dizi refs, hala bu dosyaya işaret ediyor; bu yüzden onları kaldırmanız ve ardından veritabanını yeniden paketlemeniz gerekiyor. Yeniden paketlemeden önce bu eski katkılara dönük bir işaretçisi olan her şeyden kurtulmanız gerekiyor:

Ne kadar alan kazandığınızı görelim.

Paketlenmiş repo boyutu 8K’ya kadardır, bu da 5 MB’tan çok daha iyidir. Boyut değerinden, büyük nesnenin hala gevşek nesnelerinizin içinde olduğunu, yani gitmediğini görebilirsiniz; ancak bir itme veya sonraki kopyalamayla (clone) aktarılmayacaktır ki önemli olan da budur. Eğer gerçekten isterseniz`git prune` komutunu --expire seçeneğiyle çalıştırarak nesneyi tamamen kaldırabilirsiniz: