Lugar de imagem é fora do repositório git

Após vários anos trabalhando com o git e desenvolvendo sites eu cheguei a conclusão de que lugar de imagem é fora do repositório git, deixa eu te explicar o motivo.

Quando se cria um projeto de longo prazo como um website, por mais que seja institucional, hora ou outra este projeto ficará grande. E eu não digo grande em termos de conteúdo, estou dizendo que ficará grande em termos de repositório. O git guarda tudo o que você imaginar, até mesmo os commits que você acha que você perdeu. Os commits que você fez e nunca jogou na master continuam salvos no repositório e se eles ainda forem referenciados de alguma maneira jamais serão excluídos pelo coletor de lixo.

As imagens fazem o papel maior no tamanho do histórico, pois é comum que as imagens sejam alteradas com frequência, não só a pedido do cliente como também durante o próprio desenvolvimento. Esse histórico de alterações permanece na árvore de commits e faz com que o repositório aumente de tamanho com o tempo. Logo você chegará ao limite da hospedagem e terá que criar um repositório novo contendo somente o estado atual do site. Além disso, o tempo que se leva para fazer o clone do repositório é muito maior devido à transferência de histórico desnecessário.

Com isso eu pretendo dar algumas soluções de como você pode hospedar essas imagens (e quaisquer outros arquivos estáticos) e não cometer os mesmos erros que eu, principalmente se você for um desenvolvedor iniciante.

Repositório extra

É possível criar um repositório externo e guardar as suas imagens através do git, com histórico e classificação. A sugestão que eu dou é trabalhar com ramificações separadas durante o desenvolvimento e no momento da entrega limpar todos os commits e gerar uma nova tag após colocar na master. Desse jeito somente as versões finais ficam no histórico do repositório e as versões irrelevantes das imagens ficam a cargo do coletor de lixo que executa uma vez por semana no Github.

As versões finais deste repositório extra podem ser referenciadas através de um submódulo do git e salvas no histórico do repositório principal, que contém toda codificação do website que você está trabalhando.

Só tenha em mente que, caso algum dia você precise tirar do ar este repositório (seja por custos de hospedagem ou limitação do próprio Github) você terá um histórico quebrado e não poderá revisitar as versões antigas do seu website. Você poderá apenas ver o código-fonte, mas não verá as imagens e quaisquer arquivos estáticos referenciados.

CDN ou hospedagem estática

Outra alternativa é manter os arquivos em um serviço de CDN gratuito como o ImageKit ou hospedar em um servidor privado e manter apenas uma URL no seu histórico de alterações de código. Isso é muito mais leve e prático, pois você não precisa se preocupar com o tamanho do repositório aumentando com o tempo e tampouco com submódulos do git que nada mais são do que dependências que fragilizam o código-fonte.

Caso prefira esta abordagem, prepare o seu código para exibir algo para o caso das imagens não existirem na sua CDN. É possível fazer isso da seguinte forma em ReactJS:

import { createElement, FC, useState } from 'react';
import FallbackImage from '@some-library/icons/FallbackImage';

interface ImageProps {
  src: string;
  alt: string;
}

const Image: FC<ImageProps> = ({ src, alt }) => {
  const [currentImage, setCurrentImage] = useState(src);
  return createElement('img', {
    src: currentImage,
    alt,
    onError: () => setCurrentImage(FallbackImage),
  });
};

export default Image;

A mesma precaução é válida caso decida usar um submódulo. No caso do submódulo não existir o seu site exibirá uma imagem alternativa, preferencialmente de uma biblioteca longe do repositório do seu código.

Banco de dados

Esta opção está mais para uma prova de conceito do que uma sugestão real para projetos em produção. O projeto Rafinha API de minha autoria guarda as imagens em formato de blob em um banco de dados e depois serve elas por APIs públicas em um formato otimizado como se as imagens estivessem sidos hospedadas estaticamente.

A maior vantagem em se guardar imagens num SGBD¹ é que elas serão tratadas como dados críticos e estarão sujeitas a todos os mecanismos de segurança que uma base pode te oferecer, como atomicidade, garantia de integridade, etc. Assim como controle de acesso, estatísticas de acesso e becapes mais seguros. O projeto faz uso pesado do proxy reverso e do cache HTTP para não reprocessar as imagens, dando assim pouca ou nenhuma carga para o banco de dados.

Logicamente uma abordagem dessa só faz sentido para sites onde as imagens são muito cruciais para o funcionamento do negócio, como um site de fotografias, por exemplo, onde o produto principal é a imagem. Nos demais casos a CDN convencional deve ser mais do que suficiente para atender as suas necessidades como desenvolvedor.

O que manter e não manter no git?

Dê preferência a arquivos em texto puro, como código-fonte, documentação, ícones em SVG, etc. Não guarde arquivos em formato binário como fontes, documentos em PDF, executáveis de sistema operacional, vídeo e áudio. Se o requisito for especificamente esse, de manter o histórico de alterações, então utilize a abordagem do submódulo. Caso o histórico de alteração de imagens não tenha importância para o negócio então prefira a abordagem da CDN sem versionamento. O seu desenvolvedor do futuro agradece.

É isso.