"Depende." Para rastreamento de desenvolvimento normal, não. Para implantações em nuvem e DevOps, no entanto, muitas vezes é conveniente ou até necessário.
Na maioria das vezes,
@ptyx está correto . De fato, seu "não" poderia ser declarado de maneira um pouco mais enfática. Algo como "Não. Não! OMG NÃO! "
Por que não armazenar ativos compactados ou minificados no sistema de controle de origem como o Git?
Eles podem ser quase trivialmente regenerados pelo seu processo de criação em tempo real a partir do código-fonte. Armazenar ativos compactados é basicamente armazenar o mesmo conteúdo lógico duas vezes. Ele viola o princípio "não se repita" (também conhecido como DRY ).
Um motivo menos filosófico, mas mais prático, é que os ativos minificados / otimizados têm uma compressibilidade muito baixa quando armazenados no Git. Os sistemas de controle de origem funcionam reconhecendo as alterações ("deltas") entre diferentes versões de cada arquivo armazenado. Para fazer isso, eles "diferenciam" o arquivo mais recente da versão anterior e usam esses deltas para evitar o armazenamento de uma cópia completa de todas as versões do arquivo. Porém, as transformações feitas na etapa minify / optimize frequentemente removem as semelhanças e pontos de referência usados pelos algoritmos diff / delta . O exemplo mais trivial é remover quebras de linha e outros espaços em branco; o ativo resultante geralmente é apenas uma longa fila. Muitas partes do processo de criação da Web - ferramentas como Babel , UglifyJS , Browserify ,Menos e Sass / SCSS - transformam agressivamente ativos. Sua produção é perturbável; pequenas alterações de entrada podem levar a grandes mudanças na saída. Como resultado, o algoritmo diff geralmente acredita que vê quase sempre um arquivo completamente diferente. Seus repositórios crescerão mais rapidamente como resultado. Seus discos podem ser grandes o suficiente e suas redes rápidas o suficiente, o que não é uma grande preocupação, especialmente se houver um valor em armazenar os ativos minimizados / otimizados duas vezes - embora, com base no ponto 1, as cópias extras possam ser 100% inúteis inchar.
Porém, há uma grande exceção: implantações de DevOps / nuvem. Vários fornecedores de nuvem e equipes de DevOps usam o Git e similares, não apenas para rastrear atualizações de desenvolvimento, mas também para implantar ativamente seus aplicativos e ativos em servidores de teste e produção. Nesta função, a capacidade do Git de determinar com eficiência "quais arquivos foram alterados?" é tão importante quanto sua capacidade mais granular de determinar "o que mudou em cada arquivo?" Se o Git tiver que fazer uma cópia quase completa do arquivo para ativos minimizados / otimizados, isso levará um pouco mais do que normalmente, mas não é grande coisa, pois ainda está fazendo um excelente trabalho, ajudando a evitar uma cópia de "todos os arquivos do projeto" em cada ciclo de implantação.
Se você estiver usando o Git como um mecanismo de implantação, o armazenamento de ativos minimizados / otimizados no Git poderá mudar de "não!" desejável. De fato, pode ser necessário, digamos, se você não tiver oportunidades robustas de compilação / pós-processamento nos servidores / serviços nos quais você implementa. (Como segmentar ativos de desenvolvimento e implantação, nesse caso, é uma lata separada de worms. Por enquanto, basta saber que pode ser gerenciado de várias maneiras, inclusive com um único repositório unificado, várias ramificações, sub-repositórios ou mesmo vários repositórios sobrepostos. )
/dev/null.