Gerenciando arquivos binários grandes com o Git


523

Estou procurando opiniões sobre como lidar com arquivos binários grandes dos quais meu código-fonte (aplicativo Web) depende. No momento, estamos discutindo várias alternativas:

  1. Copie os arquivos binários manualmente.
    • Pro: Não tenho certeza.
    • Contra: Sou totalmente contra isso, pois aumenta a probabilidade de erros ao configurar um novo site / migrar o antigo. Constrói outro obstáculo a ser enfrentado.
  2. Gerencie todos eles com o Git .
    • Pro: remove a possibilidade de 'esquecer' de copiar um arquivo importante
    • Contra: Incha o repositório e diminui a flexibilidade para gerenciar a base de código e checkouts, clones etc. levarão um bom tempo.
  3. Repositórios separados.
    • Pro: O check-out / clonagem do código-fonte está mais rápido do que nunca e as imagens são arquivadas corretamente em seu próprio repositório.
    • Contra: remove a simplicidade de ter o único repositório Git no projeto. Certamente introduz algumas outras coisas em que não pensei.

Quais são suas experiências / pensamentos sobre isso?

Além disso: alguém tem experiência com vários repositórios Git e com o gerenciamento deles em um projeto?

Os arquivos são imagens para um programa que gera PDFs com esses arquivos. Os arquivos não mudam com muita frequência (como em anos), mas são muito relevantes para um programa. O programa não funcionará sem os arquivos.


26
E quando a versão que controla o arquivo binário é necessária? Estou pensando em equipes de artistas trabalhando em ativos.
Dan

3
Se for necessário, você deverá equilibrar seus recursos disponíveis (disco, largura de banda, tempo de CPU) com os benefícios que obter.
pi.

4
Observe que, sem o bloqueio de arquivos, o git não é ótimo quando várias pessoas precisam trabalhar no mesmo arquivo binário.
yoyo


Respostas:


177

Se o programa não funcionar sem os arquivos, parece que dividi-los em um repositório separado é uma má idéia. Temos grandes suítes de teste que dividimos em um repositório separado, mas esses são arquivos verdadeiramente "auxiliares".

No entanto, você pode gerenciar os arquivos em um repositório separado e usá git-submodule-los para atraí-los para o seu projeto de maneira sã. Então, você ainda teria o histórico completo de toda a sua fonte, mas, pelo que entendi, você teria apenas uma revisão relevante do submódulo de suas imagens. O git-submodulerecurso deve ajudá-lo a manter a versão correta do código alinhada com a versão correta das imagens.

Aqui está uma boa introdução aos submódulos do Git Book.


11
"Pelo que entendi, você teria apenas uma revisão relevante do submódulo de suas imagens". Eu não acho que isso esteja correto.
Robin Green

22
De fato. Um submódulo é um repositório Git completo, que por acaso está aninhado dentro do repositório pai. Ele conhece toda a sua história. Você pode confirmar com menos frequência, mas se você armazenar as mesmas coisas que teria nos pais, os mesmos problemas que os pais teriam.
Cascabel

5
Esta é uma solução muito ruim se você tiver arquivos binários grandes que estão sendo alterados em algum intervalo regular. Temos um repositório que está terrivelmente inchado porque um novo arquivo binário é armazenado nele a cada compilação. Se você não estiver no Windows, como mencionado abaixo, o Anexo é uma boa solução. Se você estiver no Windows ... terá apenas que continuar procurando.
AA Grapsas 18/07/12

4
Outro problema em ter grandes arquivos binários no repositório é o desempenho. O Git não foi projetado para lidar com grandes arquivos binários e, uma vez que o tamanho do repositório sobe para 3G +, o desempenho cai rapidamente. Isso significa que ter binários grandes no repositório limita suas opções de hospedagem.
zoul

Os submódulos podem reduzir os requisitos de transferência de dados de checkout se você usar o submódulo de maneira criativa: quando quiser atualizar o conteúdo do submódulo, crie uma nova confirmação sem um pai e aponte o superprojeto (repositório principal do git) para a confirmação criada recentemente sem um pai. Logicamente, isso cria um histórico desconectado para o submódulo, mas, em troca, qualquer versão do submódulo é mais fácil de transferir porque essa versão não possui histórico.
Mikko Rantalainen

310

Descobri recentemente o git-anexo, que acho incrível. Foi projetado para gerenciar arquivos grandes com eficiência. Eu o uso para minhas coleções de fotos / músicas (etc.). O desenvolvimento do git-anexo é muito ativo. O conteúdo dos arquivos pode ser removido do repositório Git, apenas a hierarquia da árvore é rastreada pelo Git (por meio de links simbólicos). No entanto, para obter o conteúdo do arquivo, é necessário um segundo passo após puxar / empurrar, por exemplo:

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

Existem muitos comandos disponíveis e há uma excelente documentação no site. Um pacote está disponível no Debian .


11
Uau! Voto positivo por grandiosidade! Isso implementa uma ideia que eu tive recentemente e muito mais. Está escrito em Haskell, não menos. A propósito, o git-media é uma boa alternativa.
cdunn2001

33
Mas, o anexo não oferece suporte ao Windows. O que é problemático para desenvolvedores de jogos.
AA Grapsas 18/07/12

7
Ouvi dizer que o Steam está retirando o suporte para Windows e adicionando suporte para Linux ...;) sério, quão difícil pode ser portar isso? Eu acho que seu desenvolvedor de jogos comum poderia fazer isso.
Sam Watkins

4
@EstebanBrenes O verdadeiro problema é que, na configuração normal, os links simbólicos do Windows exigem privilégios elevados para serem criados.
Laurens Holst

4
Acabei de encontrar esta página . Lê que agora também git annexestá disponível no Windows . Se alguém já o testou no Windows, gostaria de saber sobre sua experiência!
Kouichi C. Nakamura

49

Outra solução, desde abril de 2015, é o LFS (Git Large File Storage) (do GitHub).

Ele usa git-lfs (consulte git-lfs.github.com ) e é testado com um servidor que o suporta: lfs-test-server :
você pode armazenar metadados somente no repositório git e no arquivo grande em outro lugar.

https://cloud.githubusercontent.com/assets/1319791/7051226/c4570828-ddf4-11e4-87eb-8fc165e5ece4.gif


3
lfs-test-serveré declarado não para uso em produção. Na verdade, estou trabalhando no servidor LFS de produção ( github.com/artemkin/git-lfs-server ). Está em andamento, mas já pode ser reparado, e estamos testando-o internamente.
Stas

Você pode fazer o check-out das versões anteriores desse arquivo binário usando o git lfs?
Mucaho 23/03

1
@mucaho Você deve: a sintaxe do git checkout permanece inalterada e o script lfs smudge ainda deve ser chamado.
VonC 23/03

31

Dê uma olhada no git bup que é uma extensão do Git para armazenar binários grandes de maneira inteligente em um repositório do Git.

Você gostaria de tê-lo como um submódulo, mas não precisará se preocupar com o repositório ficando difícil de manusear. Um de seus casos de uso de amostra é armazenar imagens de VM no Git.

Na verdade, não vi melhores taxas de compactação, mas meus repositórios não possuem binários realmente grandes.

Sua milhagem pode variar.


3
O bup fornece armazenamento (internamente usando arquivos de paridade para redundância e git para compactação, desduplicação e histórico), mas não estende o git. O git-anexo é uma extensão git que fornece um back-end de armazenamento bup .
Tobu

@Tobu quando publiquei isso, o anexo git ainda não existia (nos principais lançamentos) #
2121

2
O bup é definitivamente interessante para gerenciar arquivos grandes. Eu queria destacar uma diferença na interface do usuário: você usa comandos bup fora de qualquer contexto de repositório e git é um detalhe de implementação.
Tobu

27

Você também pode usar git-fat . Eu gosto que só depende de estoque Python e rsync. Ele também suporta o fluxo de trabalho Git usual, com os seguintes comandos auto-explicativos:

git fat init
git fat push
git fat pull

Além disso, você precisa fazer o check-in de um arquivo .gitfat no seu repositório e modificar seus atributos .gitatat para especificar as extensões de arquivo que deseja git fatgerenciar.

Você adiciona um binário usando o normal git add, que por sua vez chama com git fatbase em suas regras de gitattributes.

Por fim, tem a vantagem de que o local onde seus binários estão realmente armazenados pode ser compartilhado entre repositórios e usuários e suporta qualquer coisa rsync faz.

ATUALIZAÇÃO: Não use git-fat se estiver usando uma ponte Git-SVN. Isso acabará removendo os arquivos binários do seu repositório Subversion. No entanto, se você estiver usando um repositório Git puro, ele funcionará perfeitamente.


26

Eu usaria submódulos (como Pat Notz) ou dois repositórios distintos. Se você modificar seus arquivos binários com muita frequência, tentarei minimizar o impacto do enorme repositório que limpa o histórico:

Eu tive um problema muito parecido há vários meses: ~ 21 GB de arquivos MP3, não classificados (nomes ruins, id3s ruins, não sei se eu gosto ou não desse arquivo MP3 ...) e replicados em três computadores.

Usei uma unidade de disco rígido externa com o repositório principal do Git e a clonei em cada computador. Então, comecei a classificá-los da maneira habitual (empurrando, puxando, mesclando ... excluindo e renomeando muitas vezes).

No final, eu tinha apenas ~ 6 GB de arquivos MP3 e ~ 83 GB no diretório .git. Eu usei git-write-treee git-commit-treecriei um novo commit, sem ancestrais de commit, e iniciei um novo ramo apontando para esse commit. O "log git" para esse ramo mostrou apenas uma confirmação.

Em seguida, excluí o ramo antigo, mantive apenas o novo ramo, excluí os ref-logs e execute "git prune": depois disso, minhas pastas .git pesavam apenas ~ 6 GB ...

Você pode "limpar" o enorme repositório de tempos em tempos da mesma maneira: seu "git clone" será mais rápido.


Fiz algo semelhante uma vez, onde tive que dividir um repositório que fundi acidentalmente em dois distintos. Padrão de uso interessante embora. :)
pi.

1
Seria o mesmo que apenas: rm -f .git; git init; git add. ; git commit -m "Lixeira no histórico."
Pat Notz

1
Sim, é o mesmo apenas no meu caso de mp3. Mas às vezes você não deseja tocar em suas ramificações e tags (sem redução de espaço em repositórios públicos), mas deseja acelerar um "git clone / fetch / pull" de apenas uma ramificação (menos espaço para dedicado a isso) repositórios de filiais).
Daniel Fanjul

13

A solução que eu gostaria de propor é baseada em filiais órfãs e um leve abuso do mecanismo de tags, doravante referido como * Armazenamento Binário de Tags Órfãs (OTABS)

TL; DR 12-01-2017 Se você pode usar o LFS do github ou algum outro fabricante, por todos os meios, deve. Se não puder, continue a ler. Esteja avisado, esta solução é um hack e deve ser tratada como tal.

Propriedades desejáveis ​​do OTABS

  • é uma solução pura apenas para git e git - realiza o trabalho sem nenhum software de terceiros (como o git-anexo) ou infraestrutura de terceiros (como o LFS do github).
  • ele armazena os arquivos binários de forma eficiente , ou seja, não incha o histórico do seu repositório.
  • git pulle git fetch, incluindogit fetch --all ainda são eficientes na largura de banda , ou seja, nem todos os binários grandes são extraídos do controle remoto por padrão.
  • funciona em Windows .
  • armazena tudo em um único repositório git .
  • permite exclusão de binários desatualizados (ao contrário do bup).

Propriedades indesejáveis ​​do OTABS

  • torna git clonepotencialmente ineficiente (mas não necessariamente, dependendo do seu uso). Se você implantar esta solução, poderá ter que aconselhar seus colegas a usar em git clone -b master --single-branch <url>vez de git clone. Isso ocorre porque o git clone, por padrão, literalmente clona todo o repositório, incluindo coisas nas quais você normalmente não gostaria de desperdiçar sua largura de banda, como confirmações não referenciadas. Retirado de SO 4811434 .
  • faz git fetch <remote> --tags largura de banda ineficiente, mas não necessariamente ineficiente de armazenamento. Você sempre pode aconselhar seus colegas a não usá-lo.
  • você terá que usar periodicamente um git gc truque para limpar seu repositório de qualquer arquivo que não desejar mais.
  • não é tão eficiente quanto bup ou git-bigfiles . Mas é respectivamente mais adequado para o que você está tentando fazer e mais pronto para uso. É provável que você tenha problemas com centenas de milhares de arquivos pequenos ou com arquivos no intervalo de gigabytes, mas continue lendo para obter soluções alternativas.

Adicionando os arquivos binários

Antes de começar, verifique se você confirmou todas as alterações, sua árvore de trabalho está atualizada e seu índice não contém alterações não confirmadas. Pode ser uma boa ideia enviar todas as suas ramificações locais para o controle remoto (github etc.), caso ocorra algum desastre.

  1. Crie uma nova ramificação órfã. git checkout --orphan binaryStufffará o truque. Isso produz uma ramificação totalmente desconectada de qualquer outra ramificação, e o primeiro commit que você fará neste branch não terá pai, o que o tornará um commit raiz.
  2. Limpe seu índice usando git rm --cached * .gitignore.
  3. Respire fundo e exclua toda a árvore de trabalho usando rm -fr * .gitignore. O .gitdiretório interno permanecerá intocado, porque o *curinga não corresponde a ele.
  4. Copie no VeryBigBinary.exe ou no VeryHeavyDirectory /.
  5. Adicione e submeta.
  6. Agora isso se torna complicado - se você empurrá-lo para o controle remoto como um ramo, todos os seus desenvolvedores farão o download na próxima vez que invocarem o git fetchentupimento de sua conexão. Você pode evitar isso pressionando uma tag em vez de um ramo. Isso ainda pode afetar a largura de banda e o armazenamento do sistema de arquivos do seu colega se ele tiver o hábito de digitar git fetch <remote> --tags, mas continue lendo para obter uma solução alternativa. Vá em frente egit tag 1.0.0bin
  7. Empurre sua etiqueta órfã git push <remote> 1.0.0bin.
  8. Para não empurrar sua ramificação binária por acidente, você pode excluí-la git branch -D binaryStuff. Seu commit não será marcado para coleta de lixo, porque uma tag órfã apontando nele 1.0.0biné suficiente para mantê-lo ativo.

Verificando o arquivo binário

  1. Como faço para (ou meus colegas) obter o VeryBigBinary.exe na árvore de trabalho atual? Se o seu ramo de trabalho atual é, por exemplo, mestre, você pode simplesmente git checkout 1.0.0bin -- VeryBigBinary.exe.
  2. Isso falhará se você não tiver 1.0.0binbaixado a tag órfã ; nesse caso, você precisará fazê-lo com git fetch <remote> 1.0.0binantecedência.
  3. Você pode adicioná-lo VeryBigBinary.exeao seu mestrado .gitignore, para que ninguém em sua equipe polua o histórico principal do projeto com o binário por acidente.

Excluindo completamente o arquivo binário

Se você decidir limpar completamente o VeryBigBinary.exe do repositório local, do repositório remoto e dos repositórios de seus colegas, você pode:

  1. Exclua a marca órfã no controle remoto git push <remote> :refs/tags/1.0.0bin
  2. Exclua a marca órfã localmente (exclui todas as outras marcas não referenciadas) git tag -l | xargs git tag -d && git fetch --tags. Retirado de SO 1841341 com ligeira modificação.
  3. Use um truque git gc para excluir seu commit agora não referenciado localmente. git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@". Ele também excluirá todas as outras confirmações não referenciadas. Retirado de SO 1904860
  4. Se possível, repita o truque git gc no controle remoto. É possível se você estiver hospedando seu repositório automaticamente e não for possível com alguns provedores git, como o github ou em alguns ambientes corporativos. Se você está hospedando com um provedor que não lhe dá acesso ssh ao controle remoto, deixe estar. É possível que a infraestrutura do seu provedor limpe seu commit não referenciado em seu próprio tempo ideal. Se você estiver em um ambiente corporativo, poderá aconselhar sua TI a executar um lixo de trabalho cron, coletando seu controle remoto uma vez por semana, aproximadamente. Se eles fazem ou não, não terão nenhum impacto em sua equipe em termos de largura de banda e armazenamento, desde que você aconselhe seus colegas a sempre em git clone -b master --single-branch <url>vez de git clone.
  5. Todos os seus colegas que desejam se livrar de tags órfãs desatualizadas precisam apenas aplicar as etapas 2 a 3.
  6. Você pode repetir as etapas de 1 a 8 de Adicionando os arquivos binários para criar uma nova marca órfã 2.0.0bin. Se você está preocupado com a digitação de seus colegas, git fetch <remote> --tagspode realmente nomeá-lo novamente 1.0.0bin. Isso garantirá que, da próxima vez que buscarem todas as tags, as antigas 1.0.0binnão sejam referenciadas e marcadas para a coleta de lixo subsequente (usando a etapa 3). Ao tentar sobrescrever uma tag no controle remoto, você deve usar -fassim:git push -f <remote> <tagname>

Posfácio

  • O OTABS não toca em seu mestre nem em nenhum outro ramo de código-fonte / desenvolvimento. Os hashes de consolidação, todo o histórico e o tamanho pequeno dessas ramificações não são afetados. Se você já inchado seu histórico de código-fonte com arquivos binários, será necessário limpá-lo como um trabalho separado. Este script pode ser útil.

  • Confirmado para funcionar no Windows com git-bash.

  • É uma boa idéia aplicar um conjunto de trics padrão para tornar o armazenamento de arquivos binários mais eficiente. A execução frequente git gc(sem argumentos adicionais) faz com que o git otimize o armazenamento subjacente de seus arquivos usando deltas binários. No entanto, se é improvável que seus arquivos permaneçam similares de commit para commit, você pode desativar completamente os deltas binários. Além disso, como não faz sentido compactar arquivos já compactados ou criptografados, como .zip, .jpg ou .crypt, o git permite desativar a compactação do armazenamento subjacente. Infelizmente, é uma configuração de tudo ou nada que afeta o seu código-fonte também.

  • Você pode criar scripts de partes do OTABS para permitir um uso mais rápido. Em particular, as etapas de script 2-3 de Excluir completamente arquivos binários em um updategancho git podem fornecer uma semântica atraente, mas talvez perigosa, para o git fetch ("buscar e excluir tudo o que estiver desatualizado").

  • Você pode pular a etapa 4 de Exclusão completa de arquivos binários para manter um histórico completo de todas as alterações binárias no controle remoto, ao custo do inchaço do repositório central. Repositórios locais permanecerão enxutos com o tempo.

  • No mundo Java, é possível combinar essa solução maven --offlinepara criar uma compilação offline reproduzível, armazenada inteiramente em seu controle de versão (é mais fácil com o maven do que com o gradle). No mundo Golang, é possível desenvolver essa solução para gerenciar seu GOPATH em vez de go get. No mundo python, é possível combinar isso com o virtualenv para produzir um ambiente de desenvolvimento independente, sem depender dos servidores PyPi para todas as compilações do zero.

  • Se os seus arquivos binários mudar muito frequentemente, como artefatos de construção, pode ser uma boa idéia para o script uma solução que armazena 5 versões mais recentes dos artefatos nas tags órfãs monday_bin, tuesday_bin, ..., friday_bin, e também uma tag órfão para cada versão 1.7.8bin 2.0.0bin, etc. Você pode girar weekday_bine excluir binários antigos diariamente. Dessa forma, você obtém o melhor de dois mundos: mantém todo o histórico do seu código-fonte, mas apenas o histórico relevante das suas dependências binárias. Também é muito fácil obter os arquivos binários de uma determinada tag sem obter todo o código-fonte com todo o seu histórico: git init && git remote add <name> <url> && git fetch <name> <tag>faça isso por você.


"Você tem que usar periodicamente git gc" - parou de ler ali. Por que alguém desistiria do seu último cinto de segurança em favor de algum truque?
user1643723

@ user1643723 git gcnão é seguro para executar. Todos os seus commits pendentes será seguramente manter no disco rígido por pelo menos 30 dias por padrão: git-scm.com/docs/git-gc
Adam Kurkiewicz

Obrigado pela descrição detalhada. Eu queria tentar isso como uma maneira de armazenar algumas dependências binárias no meu repositório GitHub de forma que elas não sejam baixadas por padrão quando alguém clona o repositório, mas pode ser baixado manualmente e atualizar o repositório local. No entanto, recebi um erro nesta etapa: git push <remote> 1.0.0bin- remote: error: GH001: Large files detected. You may want to try Git Large File Storage. Parece que talvez o GitHub não esteja mais apoiando isso? O binário em questão tinha 100 MB de tamanho.
precisa saber é o seguinte

1
Para ser completamente honesto, se você tem permissão para usar o github no seu trabalho, o que o impede de usar o LFS? Os funcionários do github trabalharam duro para criar este produto e até o hospedaram para você, e sua infraestrutura é otimizada para usá-lo. Esse hack é destinado a situações em que você realmente não pode usar o LFS ou outros terceiros e está buscando uma solução pure-git.
Adam Kurkiewicz 12/01

Também atualizei a resposta para ficar mais claro sobre como essa solução é realmente hacky.
Adam Kurkiewicz

13

Na minha opinião, se é provável que você modifique esses arquivos grandes com frequência, ou se pretende criar muitos git cloneou git checkout, considere seriamente usar outro repositório Git (ou talvez outra maneira de acessar esses arquivos).

Mas se você trabalha como nós, e se seus arquivos binários não são modificados com frequência, o primeiro clone / checkout será longo, mas depois disso deve ser o mais rápido que você deseja (considerando que seus usuários continuam usando o primeiro repositório clonado que eles teve).


13
Além disso, repositórios separados não tornarão o tempo de check-out mais curto, pois você ainda precisará conferir os dois repositórios!
Emil Sit

O repositório separado do @EmilSit pode tornar o checkout muito mais curto se você limpar constantemente o histórico do "repositório binário". Além disso, os desenvolvedores não seriam forçados a fazer o checkout de ambos os repositórios de cada vez .
FabianAndre

Por que não fazer apenas o script de construção do módulo principal buscar os arquivos binários do segundo repositório, extraindo-os um a um (como aqui: stackoverflow.com/questions/1125476/… ).
6356 akauppi

1
Mesmo que seus arquivos binários não sejam alterados com frequência, os arquivos grandes ainda poderão prejudicar o seu fluxo de trabalho se você enviar por push ramificações para o repositório para fins de colaboração.
Timo Reimann 12/09

9

O SVN parece lidar com deltas binários com mais eficiência que o Git.

Eu tive que decidir sobre um sistema de controle de versão para documentação (arquivos JPEG, arquivos PDF e arquivos .odt). Acabei de testar adicionando um arquivo JPEG e girando-o 90 graus quatro vezes (para verificar a eficácia dos deltas binários). O repositório do Git cresceu 400%. O repositório do SVN cresceu apenas 11%.

Portanto, parece que o SVN é muito mais eficiente com arquivos binários.

Então, minha escolha é Git para código fonte e SVN para arquivos binários, como documentação.


33
Você só precisava executar o "git gc" (reembalagem e coleta de lixo) depois de adicionar esses 4 arquivos. O Git não comprime imediatamente todo o conteúdo adicionado, para que você tenha uma compactação de grupo de arquivos (que é mais eficiente em termos de tamanho) e não terá a lentidão de compactar separadamente todos os objetos adicionados por aí. Mas mesmo sem o "git gc", o git teria feito a compactação para você de qualquer maneira (depois que percebeu, que objetos descompactados foram acumulados).
rouxinol

24
@jpierson Criei um repositório git vazio e adicionei (e confirmei) uma imagem bmp totalmente branca com um tamanho de 41 MB, resultando em um repositório git total com um tamanho de 328 KB. Após git gco tamanho total do repositório git, foi reduzido para 184 KB. Em seguida, alterei um único pixel de branco para preto e confirmei essa alteração, o tamanho total do repositório git aumentou para 388KB e depois que git gco tamanho do repositório total git foi reduzido para 184KB. Isso mostra que o git é muito bom em compactar e encontrar deltas de arquivos binários.
Tader

6
@jpierson Uma nota lateral: acabei de comentar sobre os deltas binários. O Git consumirá toda a sua memória e será trocado se estiver gerenciando repositórios com arquivos grandes (tamanho GB). Para isso, use git-anexo (já mencionado em uma outra resposta) ...
Tader

12
@ JanDvorak - ninguém mencionou, porque é completamente falso. As cópias do Subversion são baratas - svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html - no meio da página.
Joris Timmermans

12
@ Tader: seu teste é ruim. O que você chama de arquivo binário é, de fato (da perspectiva do git), mais parecido com um arquivo de texto - o fluxo de bits é alinhado por bytes e existem diferenças significativas e localizadas a serem feitas; afinal, alterar um pixel é basicamente equivalente a alterar um caractere em um arquivo de texto (e quem usa bitmaps descompactados hoje em dia?) Experimente o mesmo experimento com um pequeno vídeo, imagem compactada, máquina virtual, arquivo zip ou qualquer outra coisa - e você encontrará que o git não lida eficientemente com o delta; na verdade, é fundamentalmente impossível com dados incompressíveis.
Eamon Nerbonne

4

git clone --filter do Git 2.19 + clones rasos

Essa nova opção pode eventualmente se tornar a solução final para o problema do arquivo binário, se o Git e o GitHub os desenvolverem e o tornarem bastante amigável (o que eles provavelmente ainda não alcançaram em sub - módulos, por exemplo).

Na verdade, ele permite buscar apenas arquivos e diretórios que você deseja para o servidor e foi apresentado juntamente com uma extensão de protocolo remoto.

Com isso, podemos primeiro fazer um clone superficial e depois automatizar quais blobs buscar no sistema de compilação para cada tipo de compilação.

Já existe um --filter=blob:limit<size>que permite limitar o tamanho máximo de blob para buscar.

Forneci um exemplo mínimo e detalhado de como o recurso se parece: Como clonar um subdiretório apenas de um repositório Git?


2

Estou procurando opiniões sobre como lidar com arquivos binários grandes dos quais meu código-fonte (aplicativo Web) depende. Quais são suas experiências / pensamentos sobre isso?

Eu, pessoalmente, deparei com falhas de sincronização com o Git com alguns dos meus hosts na nuvem, uma vez que os dados binários dos meus aplicativos da Web ultrapassam a marca de 3 GB . Eu considerava o BFT Repo Cleaner na época, mas parecia um hack. Desde então, comecei a manter os arquivos fora do alcance do Git, aproveitando as ferramentas criadas especificamente para fins específicos , como o Amazon S3, para gerenciar arquivos, controle de versão e backup.

Alguém tem experiência com vários repositórios Git e gerencia-los em um projeto?

Sim. Os temas de Hugo são gerenciados principalmente dessa maneira. É um pouco bizarro, mas faz o trabalho.


Minha sugestão é escolher a ferramenta certa para o trabalho . Se for para uma empresa e você estiver gerenciando sua linha de código no GitHub, pague o dinheiro e use o Git-LFS. Caso contrário, você poderá explorar opções mais criativas, como armazenamento de arquivos criptografado e descentralizado usando blockchain .

Opções adicionais a serem consideradas incluem Minio e s3cmd .


0

Dê uma olhada no camlistore . Não é realmente baseado em Git, mas acho mais apropriado para o que você precisa fazer.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.