Git'teki dosya sayısı (sayı ve boyut) nelerdir?

Herkes dosya sayısı ve dosya boyutu için Git sınırlarının ne olduğunu biliyor mu?

Linus'un kendisinden gelen bu mesaj size diğer bazı sınırlarda yardımcı olabilir

[...] CVS, yani gerçekten "bir seferde bir dosya" modeline yöneliyor.

Bu da bir milyon dosyanızın olması ve daha sonra bunlardan sadece birkaçına bakmanız güzel - diğer 999.995 dosyanın etkisini asla görmeyeceksiniz .

Git temelde hiçbir zaman tüm repodan daha azına bakmıyor. İşleri biraz sınırlasanız bile (yani sadece bir kısmı kontrol etseniz ya da tarihin biraz geriye gitmesini sağlasanız bile) git, her zaman her şeyi önemsiyor ve bilgiyi taşıyor.

Eğer her şeye büyük bir depo olarak bakmaya zorlarsanız git gerçekten kötü ölçeklenir . Bu parçanın gerçekten düzeltilebilir olduğunu düşünmüyorum, ancak muhtemelen geliştirebiliriz.

Ve evet, o zaman "büyük dosya" sorunları var. Büyük dosyalar hakkında ne yapacağımı gerçekten bilmiyorum. Onları emiyoruz, biliyorum.

Diğer cevabımda daha fazlasını görün : Git ile ilgili sınır, her havuzun kendi içinde "tüm sistem" olan " tutarlı bir dosya kümesi " ni temsil etmesi gerektiğidir (bir havuzun "bölümünü" etiketleyemezsiniz).
Sisteminiz otonom (ancak birbirine bağımlı) parçalardan yapılmışsa, alt modülleri kullanmalısınız .

Gösterdiği gibi Talljoe cevabı , sınırı olabilir sistem , true "sınırı" gerçekleştirecek bir (dosya çok sayıda), ancak Git doğasını anlamak yaparsanız (yaklaşık veri tutarlılık onun SHA-1 tuşları ile temsil edilir) bir kullanımdır : yani, her şeyi her zaman geri almaya veya etiketlemeye hazır değilseniz, her şeyi bir Git deposunda depolamaya çalışmamalısınız . Bazı büyük projeler için bunun bir anlamı olmaz.

Git sınırlarına daha ayrıntılı bir bakış için bkz. " Büyük dosyalarla git "
( git-lfs : büyük dosyaları git deposunun dışında saklamak için bir çözüm. GitHub, Nisan 2015)

Git deposunu sınırlayan üç sorun:

• büyük dosyalar ( packfile için xdelta yalnızca bellekte, büyük dosyalar için iyi değil)
• çok sayıda dosya , yani blob başına bir dosya ve her seferinde bir paket dosyası oluşturmak için yavaş git gc.
• Büyük packfiles (büyük) packfile veri almak için verimsiz bir packfile indeksi.

Daha yeni bir ileti dizisi (Şubat 2015) Git repo'sunun sınırlayıcı faktörlerini göstermektedir :

Merkezi sunucudan birkaç eşzamanlı klon da diğer kullanıcılar için eşzamanlı diğer işlemleri de yavaşlatacak mı?

Klonlama sırasında sunucuda kilit yoktur, bu nedenle teoride klonlama diğer işlemleri etkilemez. Klonlama olsa da çok fazla bellek kullanabilir (ve eğer ulaşmanız gereken bitmap özelliğini açmazsanız çok fazla işlemci kullanabilirsiniz).

' git pull' Yavaş olacak mı?

Sunucu tarafını hariç tutarsak, ağacınızın boyutu ana faktördür , ancak 25k dosyalarınız iyi olmalıdır (linux 48k dosyaya sahiptir).

' git push'?

Bu, deponunuzun tarihinin derinliğinden veya ağacınızın genişliğinden etkilenmez, bu yüzden hızlı olmalıdır.

Ah hakemlerimizle sayısı hem etkileyebilir git-pushve git-pull.
Sanırım Stefan bu alanda benden daha iyi biliyor.

' git commit'? ( Referans 3'te yavaş olarak listelenmiştir .) ' git status'? (Görmeme rağmen 3. referansta tekrar yavaşlayın.)
(Ayrıca git-add)

Yine, ağacınızın büyüklüğü. Deponuzun büyüklüğünde, endişelenmeniz gerektiğini düşünmüyorum.

Bazı işlemler günlük görünmeyebilir, ancak web ön ucu tarafından GitLab / Stash / GitHub vb. (örneğin ' git branch --contains', çok sayıda daldan çok olumsuz etkileniyor gibi görünüyor.)

git-blame bir dosya çok değiştirildiğinde yavaş olabilir.

Gerçek bir sınır yoktur - her şey 160 bitlik bir adla adlandırılır. Dosyanın boyutu 64 bit sayı ile temsil edilebilir, bu yüzden gerçek bir sınır yoktur.

Yine de pratik bir sınır var. 880.000'den fazla dosyaya sahip ~ 8GB'lık bir havuzum var ve git gc biraz zaman alıyor. Çalışma ağacı oldukça büyüktür, bu nedenle tüm çalışma dizinini inceleyen işlemler biraz zaman alır. Bu repo sadece veri depolama için kullanılır, bu yüzden onu idare eden bir dizi otomatik araç. Repodan değişiklik çekmek, aynı verileri yeniden senkronize etmekten çok, çok daha hızlıdır.

%find . -type f | wc -l
791887
%time git add .
git add .  6.48s user 13.53s system 55% cpu 36.121 total
%time git status
# On branch master
nothing to commit (working directory clean)
git status  0.00s user 0.01s system 0% cpu 47.169 total
%du -sh .
29G     .
%cd .git
%du -sh .
7.9G    .

Çok büyük dosyalar (benim durumumda GB'ler, Cygwin, XP, 3 GB RAM) eklerseniz, bunu bekleyebilirsiniz.

ölümcül: Bellek yetersiz, malloc başarısız

Daha fazla ayrıntı burada

2/2/11 Güncellemesi: Windows 7 x64'te Tortoise Git ile benzer testere yapıldı. Tonlarca bellek kullanılmış, çok çok yavaş sistem yanıtı.

Şubat 2012'de Git'i büyük bir test deposunda test eden bir Facebook yazılım mühendisi Joshua Redstone'un Git posta listesinde çok ilginç bir konu vardı :

Test deposunda 4 milyon taahhüt, doğrusal geçmiş ve yaklaşık 1,3 milyon dosya var.

Yapılan testler, böyle bir repo için Git'in kullanılamaz olduğunu (birkaç dakika süren soğuk işlem) gösterir, ancak bu gelecekte değişebilir. Temel olarak performans, stat()çekirdek FS modülüne yapılan çağrıların sayısı ile cezalandırılır , bu nedenle repodaki dosya sayısına ve FS önbellekleme verimliliğine bağlı olacaktır. Daha fazla tartışma için bu Özete bakınız .

2018-04-20 itibariyle Windows için Git, söz konusu uygulamayı kullanarak dosya boyutunu etkili bir şekilde en fazla 4 GB ile sınırlayan bir hataya sahiptir (bu hata lfs'ye de yayılır ).

Anlamının ne olduğuna bağlı. Pratik boyut sınırları vardır (çok sayıda büyük dosyanız varsa, sıkıcı bir şekilde yavaşlayabilir). Çok fazla dosyanız varsa, taramalar da yavaşlayabilir.

Yine de, modelin doğasında var olan sınırlar yoktur. Kesinlikle kötü kullanabilir ve sefil olabilirsiniz.

Deponun bir parçası olarak büyük dosya taahhütlerinden kaçınmaya çalışmanın iyi olduğunu düşünüyorum (örneğin, bir veritabanı dökümü başka bir yerde daha iyi olabilir), ancak biri havuzundaki çekirdeğin boyutunu göz önünde bulundurursa, muhtemelen rahat çalışmayı bekleyebilirsiniz daha küçük ve daha az karmaşık bir şeyle.

Bireysel JSON parçaları olarak depolamamda saklanan cömert miktarda veri var. Birkaç dizin altında yaklaşık 75.000 dosya var ve bu performans için gerçekten zararlı değil.

Onları ilk kez kontrol etmek, biraz yavaştı.

Ben bir repo çok sayıda dosya (350k +) depolamak için çalışırken buldum. Evet, sakla. Güler.

$ time git add . 
git add . 333.67s user 244.26s system 14% cpu 1:06:48.63 total

Bitbucket belgelerinden aşağıdaki alıntılar oldukça ilginçtir.

Bir DVCS veri havuzu klonlama, itme ile çalışırken, tüm veri havuzu ve tüm geçmişi ile çalışırsınız. Uygulamada, deponuz 500 MB'den büyük olduğunda, sorunları görmeye başlayabilirsiniz.

... Bitbucket müşterilerinin% 94'ünde 500MB'ın altında depolar var. Hem Linux Çekirdeği hem de Android 900MB'ın altında.

Bu sayfada önerilen çözüm, projenizi daha küçük parçalara bölmektir.

git'in repo için 4G (32bit) limiti vardır.

http://code.google.com/p/support/wiki/GitFAQ