.gitignore Tudo por Padrão

Artigo original ↗ Discussão no Hacker News ↗

Defensores de “.gitignore everything by default” argumentam que isso reduz o risco de commitar acidentalmente segredos, lixo de SO ou artefatos de IDE, especialmente quando as pessoas usam habitualmente `git add .`. Críticos respondem que essa abordagem oculta arquivos novos do `git status`, aumenta a chance de faltar arquivos importantes de código e é frágil em contextos colaborativos. Muitos recomendam, em vez disso, templates globais e por projeto de .gitignore, staging mais disciplinado (`git add -p`, evitando `git add .`) ou verificações por ferramentas e CI para impor o que deve e não deve ser commitado.

Reação geral a “.gitignore everything by default”

  • Muitos consideram isso ruim ou exagerado: há o risco de esquecer de des-ignorar arquivos importantes, quebrar builds/CI e esconder arquivos ausentes do git status.
  • Os defensores veem isso como uma estratégia defensiva, de “negar por padrão” / orientada à segurança, para evitar commits acidentais de segredos, lixo ou resíduos específicos de ferramentas.
  • Vários observam que funciona melhor para certos contextos (por exemplo, contextos de build do Docker, experimentos em Unity, repositórios rigidamente estruturados) do que para desenvolvimento geral.

Staging seletivo vs git add . em bloco

  • Tema forte: evite git add . / git add -A às cegas.
    • Alternativas defendidas: git add -u, git add -p, staging interativo e revisar git status antes/depois de adicionar.
  • Alguns estruturam o trabalho para que git add . seja seguro (árvore limpa, uma única mudança coerente).
  • Há discordância sobre reversibilidade: alguns acham que “adicionar tudo” é fácil de desfazer; outros apontam que muitos usuários não sabem ou não usam git reset / git restore --staged.

Estratégias globais e locais de ignore

  • Amplamente recomendado: um ignore global do usuário (~/.config/git/ignore ou similar) para arquivos de SO/editor/ferramentas (.DS_Store, configs de IDE, lixo de Emacs/Vim).
  • Outros argumentam que o .gitignore no nível do repositório ainda deve ignorar de forma defensiva artefatos comuns de SO/editor, já que nem todos mantêm um ignore global.
  • Padrões populares:
    • Ignorar todos os dotfiles globalmente (.*) mas re-ignorar explicitamente os importantes (!.gitignore, !.editorconfig, etc.).
    • Diretórios dedicados de scratch/playground ou .gitignore por diretório com * para arquivos descartáveis.
    • Usar .git/info/exclude para ignores pessoais, locais ao repositório, que não são compartilhados.

Arquivos de configuração de IA/agentes (por exemplo, CLAUDE.md)

  • Há discordância sobre se isso deve ficar no repositório:
    • Alguns veem instruções de IA em nível de projeto como documentação compartilhada útil.
    • Outros veem isso como despejo de preferências pessoais, mais próximo de configs de editor, e preferem uma variante estilo .local, ignorada pelo git.

Ferramentas, CI e salvaguardas alternativas

  • Vários recomendam GUIs/TUIs (Magit, lazygit, tig, integrações de IDE) para diffs visuais e staging por hunk.
  • Alguns usam linters/hooks (por exemplo, alint) ou regras de CI para bloquear caminhos não permitidos.
  • Falhar no CI por arquivos ausentes é visto como menos danoso do que vazar segredos, mas אחרים se preocupam com trabalho perdido e problemas de “funciona na minha máquina”.