Mevcut üssümün toplam boyutu yakl. 200MB.
Ancak .git klasörümün inanılmaz bir boyutu 5 GB (!). Çalışmamı harici bir sunucuya ittiğim için büyük bir yerel geçmişe ihtiyacım yok ...
Not defterimde biraz yer açmak için .git klasörünü nasıl küçültebilirim? 30 günden daha eski olan tüm değişiklikleri silebilir miyim?
herhangi bir yardım için çok teşekkürler :)
Yanıtlar:
30 günden daha eski tüm değişiklikleri silmemelisiniz (bence bir şekilde git'i istismar etmek mümkün, ancak gerçekten tavsiye edilmiyor).
Çağrabilirsiniz git gc --aggressive --prune, bu da deponuzda çöp toplama işlemini gerçekleştirecek ve eski nesneleri budayacaktır. Sık sık değişen çok sayıda ikili dosyanız (arşivler, resimler, çalıştırılabilir dosyalar) var mı? bunlar genellikle çok büyük .git klasörlerine yol açar (unutmayın, git her revizyon için anlık görüntüleri depolar ve ikili dosyalar kötü şekilde sıkıştırılır)
git gc --aggressivekötü bir uygulama olarak kabul edilir. Kullanması daha iyi git repack -a -d --depth=250 --window=250.
git gc --aggressivepencere boyutu 250 (kılavuz sayfa) ve derinliği 250 (kaynak kodu ile karşılaştırın) ile yeniden paketlemeyi çağırır. --aggressive ayrıca -fönceki tüm delta işlemlerini atmak ve yeniden yapmak için anahtarı ekler (bağlantıda da bahsedildiği gibi)
git gc --aggressive --prunebunu 19MB'ye düşürdü.
--pruneo zamandan beri varsayılan olduğu için de gerekli değildir v1.5.5-rc0(taahhüt 25ee973 , Mart 2008).
Git Linus'un yaratıcısının git deponuzu nasıl küçülteceğinizle ilgili söyledikleri:
"Git gc --agresif" nin eşdeğeri - ancak * doğru bir şekilde * yapılır - şöyle bir şey yapmaktır (bir gecede)
git repack -a -d --depth=250 --window=250burada bu derinlik meselesi, delta zincirlerinin ne kadar derin olabileceğiyle ilgilidir (eski tarih için onları daha uzun hale getirin - uzay ek yüküne değer) ve pencere meselesi, her delta adayının taramasını istediğimiz nesne penceresinin ne kadar büyük olduğuyla ilgilidir.
Ve buraya "-f" bayrağını eklemek isteyebilirsiniz (ki bu "tüm eski deltaları bırak" dır, çünkü şimdi bunun gerçekten iyi adaylar bulduğundan emin olmaya çalışıyorsunuz.
kaynak: http://gcc.gnu.org/ml/gcc/2007-12/msg00165.html
Bu, depomda öksüz kalan ikili verilerden kurtulacak mı? "git repack", deponuza koyduğunuz ve daha sonra sildiğiniz resimleri veya ikili verileri ortadan kaldırmaz. Bu tür verileri deponuzdan kalıcı olarak silmek için geçmişinizi yeniden yazmanız gerekir. Bunun yaygın bir örneği, git'te şifrelerinizi yanlışlıkla kontrol etmenizdir. Geri dönüp bazı dosyaları silebilirsiniz, ancak daha sonra geçmişinizi o zamandan bugüne yeniden yazmanız ve ardından yeni depoyu kaynağınıza zorla itmeniz gerekir.
fatal: Out of memory, malloc failed (tried to allocate 39763130 bytes)
repackYerel olarak çalıştırdıktan sonra , bir commit ve push yaparak, küçültme işlemi de uzaktan yapılacak mı?
Bunları denedim ama depom hala çok büyüktü. Sorun, oluşturulan bazı büyük dosyaları yanlışlıkla kontrol etmiş olmamdı. Biraz aramadan sonra, oluşturulan büyük dosyaları silmeyi kolaylaştıran harika bir eğitim buldum. Bu eğitim, depomu 60 MB'den <1 MB'ye düşürmeme izin verdi.
5GB vs 200MB biraz tuhaf. Koşmayı denegit gc .
Ama hayır, deponuzu modüllere ayırmadıkça, boyutunu küçültemezsiniz. .git dizinin küçültemezsiniz.
Bir git deposunun her klonu, bir sunucu görevi görebilen tam teşekküllü bir depodur. Dağıtılmış sürüm kontrolünün temel ilkesi budur.
Git'i sürüm geçmişinden çok senkronizasyon mekanizması olarak kullanıyorum. Bu yüzden bu soruna çözümüm, mevcut tüm kaynaklarımın tatmin edici bir durumda olduğundan emin olmak ve ardından .git'i silip depoları yeniden başlatmaktı. Disk alanı sorunu çözüldü. :-) Geçmiş gitti :-( Bunu yapıyorum çünkü depom küçük bir USB anahtarında. Tüm geçmişimi istemiyorum ya da ihtiyacım yok. Sadece geçmişi kesmek için bir yöntemim olsaydı, onu kullanırdım.
Geçmişimi saklamakla ilgileniyor olsaydım, mevcut depoyu arşivlerdim. Daha sonra bir noktada orijinal depoyu klonlayabilir, yeni depodaki tüm değişiklikleri kopyalayabilirim (çok fazla (herhangi bir) yeniden adlandırma veya silme yapmadığımı varsayalım). Ve sonra yeni depoda yapılan tüm değişiklikleri eski depoda tek bir taahhüt olarak temsil edecek büyük bir taahhütte bulunun. Geçmişleri birleştirmek mümkün mü? Belki bir dal kullanıp daha sonra ihtiyacım olmayan nesneleri sildim. (Git internals hakkında böyle dalga geçmeye başlamak için yeterince bilgim yok).
Yukarıdaki yöntemler denendi, benim durumumda hiçbir şey işe yaramadı (git itme sırasında git işlemini yanlışlıkla öldürdüğümde) bu yüzden nihayet depoyu silip tekrar klonlamak zorunda kaldım ve şimdi .git klasörü normal boyutta.
git count-objects -v?