As imagens devem ser armazenadas em um repositório git?

Para uma equipe distribuída que usa Git e Github como controle de versão, as imagens também devem ser armazenadas no repositório git?

Na maior parte, as imagens não serão alteradas. A pasta que os contém aumentará de tamanho à medida que as imagens forem adicionadas. Uma preocupação é que a pasta de imagens possa crescer para um tamanho grande ao longo do tempo pela combinação de imagens grandes, ou apenas muitas delas.

Isso é considerado uma prática recomendada? Que outras alternativas existem para compartilhar arquivos binários necessários em projetos que uma equipe distribuída pode acessar facilmente?

Suas imagens são originais ou podem ser recuperadas (garantidas?) De outros lugares? Eles são necessários para enviar uma unidade de software construída a partir da fonte? Se forem originais, precisam fazer backup. Coloque-os no seu controle de revisão, se eles nunca mudarem, a penalidade de espaço é a mesma que um backup e eles estão onde você precisa deles.

Eles podem ser editados para alterar a aparência do software, acidental ou intencionalmente? Sim - então eles DEVEM ser controlados por revisão de alguma forma, por que usar outra maneira quando você já tem uma solução perfeita. Por que introduzir o controle de versão "copiar e renomear" da idade das trevas?

Eu vi a arte original de um projeto inteiro ficar "maluca" quando o disco rígido do MacBook do designer gráfico morreu, tudo porque alguém, com infinita sabedoria, decidiu que "os binários não pertencem ao controle de rotação" e os designers gráficos (pelo menos este ) não costumam ser bons com backups.

O mesmo se aplica a todo e qualquer arquivo binário que atenda aos critérios acima.

O único motivo para não fazer isso é espaço em disco. Receio que, com US $ 100 / terabyte, essa desculpa esteja se esgotando um pouco.

Por que diabos não? :)

Armazenar binários é considerado uma prática ruim, sim, mas nunca me preocupei muito com imagens.

Na pior das hipóteses, se você tiver toneladas, armazene-as em outro lugar ou use fontes externas ou uma extensão para suporte binário. E se as imagens não forem alteradas com tanta frequência, qual é o problema? Você não terá um grande delta gordo. E se eles forem removidos com o tempo, apenas o servidor sofrerá um pouco de armazenamento do histórico, mas os clientes não verão nada.

Na minha opinião, você não deve se preocupar com isso - desde que você não armazene GBs desses.

O que você poderia fazer, porém, é apenas armazenar imagens "de origem": SVGs, macros LaTeX, etc ... e ter as imagens finais geradas pelo seu sistema de compilação. Provavelmente é ainda melhor, se você puder. Caso contrário, não se preocupe.

(Tudo isso dito, o Git brilha para arquivos de texto, mas não é o melhor VCS para imagens. Dê-nos mais contexto e métricas, se puder)

Para informações adicionais, convém consultar estas perguntas e respostas:

• Armazenando arquivos de imagem no SubVersion / Git
• Git vs SVN com arquivos que não são de texto
• Gerenciando arquivos binários grandes com o Git e o submódulo Git

Essa pergunta é bastante antiga, mas é uma pergunta comum que surge quando se lida com o Git e há algum progresso em soluções modernas para armazenar arquivos grandes em um repositório Git desde a última resposta.

Para armazenar arquivos grandes no Git, existem os seguintes projetos:

• git-anexo - Isso já existe há algum tempo, mas, francamente, a complexidade atrapalha.
• git-media - Nenhuma experiência pessoal com este. Parece bastante complexo também.
• git-fit - Uma tentativa de criar um plugin mais simples. Requer armazenamento S3. Embora eu aprecie a simplicidade, minha principal preocupação com o plug-in é que ele é bastante desconhecido e mantido por 1 indivíduo (divulgação completa, eu sou o único outro colaborador no momento e foi por um problema trivial).
• git-lfs - Embora eu não tenha usado isso extensivamente, parece ser o Santo Graal. É apoiado pelo Github e está disponível em todos os seus repositórios a partir de outubro de 2015 e coloca a complexidade do gerenciamento de arquivos no local, armazenando seus repositórios. A única desvantagem é que isso é relativamente novo; portanto, além do Github, não há muito suporte, embora o Gitlab também tenha suporte , assim como o Gitea , e o Bitbucket aludiu ao suporte no futuro .

TLDR: se possível, use git-lfs para armazenar imagens ou outros arquivos binários no git.

O conjunto "não armazena binários no controle de origem" é definido por um motivo específico: Se você tiver um código-fonte que seja compilado, não armazene a compilação real, mas apenas o código-fonte. As imagens e os recursos visuais não têm uma "fonte", portanto devem ser rastreados no controle de versão.

Acredito que a maneira recomendada com o Git é usar um submódulo (introduzido no Git 1.5.3) que é basicamente um repositório separado que está associado ao principal. Você armazena suas imagens (e outros ativos binários) no submódulo. Isso pode ser verificado com o repositório principal ou deixado, dependendo do que for necessário.

Em http://book.git-scm.com/5_submodules.html

"O suporte ao submódulo do Git permite que um repositório contenha, como subdiretório, uma verificação de um projeto externo. Os submódulos mantêm sua própria identidade; o suporte ao submódulo apenas armazena o local do repositório do submódulo e confirma o ID, assim outros desenvolvedores que clonam o projeto que os contém (" superproject ") pode facilmente clonar todos os submódulos na mesma revisão. É possível fazer check-outs parciais do superprojeto: você pode dizer ao Git para clonar nenhum, alguns ou todos os submódulos."

Além disso, o tamanho não deve ser um problema significativo se as imagens não mudarem com frequência. Você também pode executar comandos para remover / reduzir o tamanho, como:

git gc
git gc-aggressive
git prune

Sim .

Digamos que você libere a versão 1.0 do software. Para a versão 2.0, você decide refazer todas as imagens para ficar com sombras. Então você faz isso e lança o 2.0. Alguns clientes que estão usando 1.0 e não podem atualizar para 2.0 decidem que desejam o programa em outro idioma. Eles lhe dão US $ 1G para fazê-lo, então você tem certeza. Mas em uma cultura diferente, algumas de suas fotos não fazem sentido, então você precisa alterá-las ...

Se você mantiver suas imagens no controle de origem, isso é fácil, com base na versão 1.0, você faz alterações nas imagens (entre outras coisas), constrói, libera. Se você não os tivesse no controle de origem, teria muito mais dificuldade, pois precisaria encontrar as imagens antigas, alterá-las e depois compilar.

Se faz parte do projeto, deve estar no VCS . Como conseguir isso da melhor maneira pode depender do VCS ou como você organiza um projeto. Talvez um repositório para os designers, e apenas os resultados no repositório do codificador, ou apenas as 'Fontes de imagem' (eu já tive um projeto com apenas um arquivo .svg e as imagens foram geradas via make / inscape cli).

Mas, se um VCS não puder lidar com isso ou se tornar inútil, eu diria que não é a ferramenta certa para o seu trabalho.

Até agora, não tive problemas em colocar quantidades 'habituais' de gráficos (maquetes, conceitos e gráficos de página) para projetos da Web no git.

Você deve armazenar suas imagens no SCM: sim. Sem nenhuma dúvida.

Você deve armazenar suas imagens no git: isso fica mais complicado.

O git é muito bom com arquivos de texto, mas por sua própria natureza não é muito quente com binários. Você terá problemas com o tamanho dos dados transferidos ao clonar ou enviar por push, seus diretórios .git crescerão e você poderá ter uma confusão com a fusão (ou seja, como você mescla 2 imagens!)

Uma resposta é usar submódulos, pois isso significa que o vínculo entre seu projeto e as imagens será mais fraco - para que você não precise gerenciá-las como se elas fizessem parte da sua fonte, mantendo-as ainda controladas e não tendo se preocupa em ramificá-los - supondo que o subprojeto seja apenas um repositório "simples" de dados que não passa pela mesma rotatividade durante o processo de desenvolvimento usual.

A outra resposta é colocá-los em um projeto diferente, nunca ramificá-lo e garantir que todos os que se comprometam com esse projeto o empurram imediatamente para cima - nunca permita que duas pessoas alterem a mesma versão do arquivo - você achará o mais difícil aspecto como o git não foi projetado para um fluxo de trabalho não distribuído. Você precisará usar métodos de comunicação antiquados para seguir essa regra.

Uma terceira resposta é colocá-los em um SCM completamente diferente, mais voltado para o trabalho com imagens.

Adicionando à resposta de @ haylem, observe que o tamanho é um fator importante nisso. Dependendo do VCS, pode não funcionar bem com toneladas de imagens. Quando clones ou push grandes começam a demorar a noite toda, é realmente tarde demais, pois todas as imagens já estão no seu repositório.

Planeje fotos grandes e crescimento futuro. Você não quer entrar dois anos nesse projeto e ter uma "ah merda, talvez o repo seja um pouco grande demais ".

Definitivamente, concordo que é possível armazená-los técnica e economicamente. Pergunta que eu faria como é "essas imagens fazem parte do produto de remessa ou parte do conteúdo de um produto de remessa?" Não que você não possa armazenar conteúdo no GIT (ou em qualquer outro VCS), mas que é um problema separado para um VCS separado.