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

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

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

[…] CVS, isto é, ele acaba sendo muito orientado para um modelo “um arquivo de cada vez”.

O que é legal, pois você pode ter um milhão de arquivos, e só dar uma olhada em alguns deles – você nunca verá o impacto dos outros 999.995 arquivos.

Git fundamentalmente nunca olha realmente menos do que todo o repo. Mesmo se você limitar as coisas um pouco (ou seja, verificar apenas uma parte, ou ter a história voltar um pouco), git acaba sempre se importando com a coisa toda, e levando o conhecimento ao redor.

Então git scale realmente mal se você forçá-lo a olhar para tudo como um repository enorme . Eu não acho que essa parte seja realmente consertável, embora provavelmente possamos melhorá-la.

E sim, há os problemas de “arquivo grande”. Eu realmente não sei o que fazer com arquivos enormes. Nós somos péssimos para eles, eu sei.

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

Como 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 de dados representada por suas chaves SHA-1), você perceberá o verdadeiro “limite” é um uso : ou seja, você não deve tentar armazenar tudo em um repository Git, a menos que esteja preparado para sempre obter ou marcar tudo de volta. Para alguns grandes projetos, não faria sentido.


Para uma análise mais detalhada dos limites do git, consulte ” git with large files ”
(que menciona git-lfs : uma solução para armazenar arquivos grandes fora do repository do git. GitHub, abril de 2015)

Os três problemas que limitam um repository do git:

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

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

Alguns clones simultâneos do servidor central também retardarã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. No entanto, a clonagem pode usar muita memory (e muita CPU a menos que você ative o recurso de bitmap reachability, o que você deve).

O ‘ git pull ‘ será lento?

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

git push ‘?

Este não é afetado por quão profunda é a história do seu repo, ou quão larga é a sua tree, então deve ser rápido ..

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

git commit ‘? (Está listado como lento na referência 3. ) ‘ git status ‘? (Lento novamente na referência 3, embora eu não veja isso.)
(também git-add )

Mais uma vez, o tamanho da sua tree. No tamanho do seu repo, não acho que você precise se preocupar com isso.

Algumas operações podem não parecer estar no dia-a-dia, mas se forem chamadas freqüentemente pelo front-end da web para o GitLab / Stash / GitHub, elas podem se tornar gargalos. (por exemplo, ‘ git branch --contains ‘ parece terrivelmente adversamente afetado por um grande número de filiais.)

git-blame poderia 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, portanto não há limite real.

Existe um limite prático, no entanto. Eu tenho um repository que é ~ 8GB com> 880.000 e git gc leva um tempo. A tree de trabalho é bastante grande para que as operações que inspecionam o diretório de trabalho inteiro demorem bastante. Este repository é usado apenas para armazenamento de dados, por isso é apenas um monte de ferramentas automatizadas que lidam com isso. Puxar mudanças do repo é muito, muito mais rápido do que rsyncing 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 que são muito grandes (GB no meu caso, Cygwin, XP, 3 GB de RAM), espere isso.

fatal: sem memory, malloc falhou

Mais detalhes aqui

Atualização 3/2/11: Vi semelhante no Windows 7 x64 com o Tortoise Git. Toneladas de memory usada, resposta muito lenta do sistema.

Em fevereiro de 2012, havia um tópico muito interessante na lista de discussão do Git de Joshua Redstone, um engenheiro de software do Facebook testando o Git em um enorme repository de teste:

O repo de teste tem 4 milhões de commits, histórico linear e cerca de 1,3 milhões de arquivos.

Testes que foram executados mostram que, para tal repo, o Git é inutilizável (operação a frio dura alguns minutos), mas isso pode mudar no futuro. Basicamente, o desempenho é penalizado pelo número de chamadas stat() para o módulo FS do kernel, portanto, dependerá do número de arquivos no repository e da eficiência do armazenamento em cache do FS. Veja também esta essência para uma discussão mais aprofundada.

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

Não há limites inerentes ao modelo, no entanto. Você certamente pode usá-lo mal e ser infeliz.

Eu acho que é bom tentar evitar commits de arquivos grandes como parte do repository (por exemplo, um dump de database pode ser melhor em outro lugar), mas se considerarmos o tamanho do kernel em seu repository, você pode esperar trabalhar confortavelmente com qualquer coisa menor em tamanho e menos complexo que isso.

Eu tenho uma quantidade generosa de dados armazenados em meu repository como fragments JSON individuais. Há cerca de 75.000 arquivos em alguns diretórios e não é prejudicial ao desempenho.

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

Eu encontrei este tentando armazenar um enorme número de arquivos (350k +) em um repo. 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 repository DVCS, push, você está trabalhando com todo o repository e todo o seu histórico. Na prática, quando o seu repository ultrapassar 500 MB, você poderá começar a ver os problemas.

… 94% dos clientes do Bitbucket têm repositorys com menos de 500MB. O kernel do Linux e o Android estão abaixo de 900MB.

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

A partir de 2018-04-20 Git for Windows tem um bug que efetivamente limita o tamanho do arquivo para 4GB max usando essa implementação particular (este bug também se propaga para lfs ).

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

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