Quais são os limites de arquivo no Git (número e tamanho)?

Alguém sabe quais são os limites do Git para número de arquivos e tamanho dos arquivos?

Esta mensagem do próprio Linus pode ajudá-lo com outros limites

[...] CVS, ou seja, ele realmente acaba sendo orientado a um modelo de "um arquivo por vez".

O que é bom, pois você pode ter um milhão de arquivos e verificar apenas alguns deles - você nunca verá o impacto dos outros 999.995 arquivos.

Git fundamentalmente nunca realmente olha menos do que todo o repositório. Mesmo se você limitar um pouco as coisas (por exemplo, confira apenas uma parte ou a história voltar um pouco), o git acaba sempre se preocupando com a coisa toda e levando o conhecimento ao redor.

Portanto, o git é muito ruim se você forçar a olhar para tudo como um grande repositório. Não acho que essa parte seja realmente corrigível, embora provavelmente possamos melhorá-la.

E sim, há os problemas de "arquivo grande". Realmente não sei o que fazer com arquivos enormes. Nós somos péssimos, eu sei.

Veja mais na minha outra resposta : o limite com o Git é que cada repositório deve representar um " conjunto coerente de arquivos ", o "sistema todo" em si (você não pode marcar "parte de um repositório").
Se o seu sistema é constituído por partes autônomas (mas interdependentes), você deve usar submódulos .

Conforme ilustrado pela resposta de Talljoe , o limite pode ser um sistema (grande número de arquivos), mas se você entender a natureza do Git (sobre a coerência dos dados representada por suas chaves SHA-1), perceberá o verdadeiro "limite" é um exemplo de uso : ou seja, você não deve tentar armazenar tudo em um repositório Git, a menos que esteja preparado para sempre obter ou marcar tudo de volta. Para alguns projetos grandes, não faria sentido.

Para uma visão mais aprofundada dos limites do git, consulte " git com arquivos grandes "
(que menciona o git-lfs : uma solução para armazenar arquivos grandes fora do repositório git. GitHub, abril de 2015)

Os três problemas que limitam um repositório git:

• arquivos enormes (o xdelta para packfile está apenas na memória, o que não é bom em arquivos grandes)
• um grande número de arquivos , o que significa, um arquivo por blob e o git gc lento para gerar um arquivo de pacote por vez.
• pacotes de arquivos enormes , com um índice de arquivo de pacotes ineficiente para recuperar dados do (enorme) pacote de arquivos.

Um tópico mais recente (fevereiro de 2015) ilustra os fatores limitantes para um repositório Git :

Alguns clones simultâneos do servidor central também desacelerarão outras operações simultâneas para outros usuários?

Não há bloqueios no servidor durante a clonagem, portanto, em teoria, a clonagem não afeta outras operações. Porém, a clonagem pode usar muita memória (e muita CPU, a menos que você ative o recurso de bitmap de acessibilidade, o que você deve).

Será git pulllento?

Se excluirmos o lado do servidor, o tamanho da sua árvore é o principal fator , mas seus arquivos de 25k devem ficar bem (o linux tem 48k).

' git push'?

Este não é afetado pela profundidade da história do seu repositório ou pela largura da sua árvore; portanto, deve ser rápido.

Ah, o número de árbitros pode afetar ambos git-pushe git-pull.
Eu acho que Stefan sabe melhor do que eu nesta área.

' git commit'? (Ele está listado como lento na referência 3. ) ' git status'? (Lento novamente na referência 3, embora não o veja.)
(Também git-add)

Mais uma vez, o tamanho da sua árvore. No tamanho de seu repositório, acho que você não precisa se preocupar com isso.

Algumas operações podem não parecer cotidianas, mas se forem chamadas frequentemente pelo front-end da Web para GitLab / Stash / GitHub etc., poderão se tornar gargalos. (por exemplo, ' git branch --contains' parece terrivelmente afetado adversamente por um grande número de ramificações.)

git-blame pode ser lento quando um arquivo é muito modificado.

Não há limite real - tudo é nomeado com um nome de 160 bits. O tamanho do arquivo deve ser representável em um número de 64 bits, para que também não haja limite real.

Há um limite prático, no entanto. Eu tenho um repositório de aproximadamente 8 GB com mais de 880.000 arquivos e o git gc demora um pouco. A árvore de trabalho é bastante grande, portanto as operações que inspecionam todo o diretório de trabalho demoram um pouco. Porém, esse repositório é usado apenas para armazenamento de dados; portanto, são apenas um monte de ferramentas automatizadas que lidam com isso. Obter alterações do repositório é muito, muito mais rápido do que sincronizar os mesmos dados.

%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    .

Se você adicionar arquivos muito grandes (GBs no meu caso, Cygwin, XP, 3 GB de RAM), espere isso.

fatal: falta de memória, malloc falhou

Mais detalhes aqui

Atualização 3/2/11: viu similar no Windows 7 x64 com o Tortoise Git. Toneladas de memória usada, resposta do sistema muito, muito lenta.

Em fevereiro de 2012, havia uma discussão muito interessante na lista de discussão do Git de Joshua Redstone, um engenheiro de software do Facebook que testava o Git em um enorme repositório de testes:

O repositório de teste possui 4 milhões de confirmações, histórico linear e cerca de 1,3 milhão de arquivos.

Os testes executados mostram que, para tal repo, o Git é inutilizável (operação a frio com duração de minutos), mas isso pode mudar no futuro. Basicamente, o desempenho é penalizado pelo número de stat()chamadas ao módulo FS do kernel, portanto, isso depende do número de arquivos no repositório e da eficiência do cache do FS. Veja também este Gist para uma discussão mais aprofundada.

A partir de 20/04/2018, o Git for Windows possui um bug que limita efetivamente o tamanho do arquivo a 4 GB no máximo usando essa implementação específica (esse bug se propaga para o lfs também ).

Depende do seu significado. Existem limites práticos de tamanho (se você tiver muitos arquivos grandes, pode ficar muito chato). Se você tiver muitos arquivos, as verificações também podem ficar lentas.

No entanto, não existem limites inerentes ao modelo. Você certamente pode usá-lo mal e ser infeliz.

Eu acho que é bom tentar evitar a consolidação de arquivos grandes como parte do repositório (por exemplo, um despejo de banco de dados pode ser melhor em outro lugar), mas se considerarmos o tamanho do kernel em seu repositório, é provável que você espere trabalhar confortavelmente com algo menor em tamanho e menos complexo que isso.

Eu tenho uma quantidade generosa de dados armazenados no meu repositório como fragmentos JSON individuais. Existem cerca de 75.000 arquivos em alguns diretórios e isso não prejudica o desempenho.

Verificá-los pela primeira vez foi, obviamente, um pouco lento.

Achei isso tentando armazenar um grande número de arquivos (350k +) em um repositório. Sim, guarde. Risos.

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

Os seguintes extratos da documentação do Bitbucket são bastante interessantes.

Quando você trabalha com uma clonagem de repositório DVCS, pressionando, está trabalhando com todo o repositório e todo o seu histórico. Na prática, quando o seu repositório tiver mais de 500 MB, você poderá começar a ver problemas.

... 94% dos clientes do Bitbucket possuem repositórios com menos de 500 MB. Tanto o Kernel do Linux quanto o Android têm menos de 900 MB.

A solução recomendada nessa página é dividir seu projeto em partes menores.

O git tem um limite de 4G (32 bits) para repo.

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