.gitignore Não é a única forma de ignorar ficheiros no Git

Artigo original ↗ Discussão no Hacker News ↗

Mecanismos de ignore por repositório vs. por utilizador/global

  • Vários comentadores destacam .git/info/exclude para ignores por repositório e por utilizador (por exemplo, scripts locais, Makefiles, dados de exemplo, notas) sem poluir o .gitignore partilhado.
  • Os ignores globais/ao nível do utilizador via ~/.config/git/ignore (ou equivalente) são enfatizados como subutilizados, ideais para lixo de SO/editor (por exemplo, .DS_Store, pastas de IDE).
  • Esclarecimento: --global no Git é por utilizador; a verdadeira configuração ao nível da máquina é --system (por exemplo, /etc/gitignore), que raramente é recomendada e pode ser sobrescrita pela configuração do utilizador.
  • Algumas ferramentas (Magit) expõem uma interface para escolher entre o .gitignore partilhado e o .git/info/exclude privado.

O que pertence ao .gitignore vs. ignores globais

  • Uma corrente defende que o .gitignore do repositório deve cobrir apenas artefactos específicos do repositório (saídas de compilação, pastas de dependências). Ficheiros específicos do utilizador/IDE/SO pertencem ao ignore global de cada programador.
  • Outra corrente: adicionar lixo comum de SO/IDE (por exemplo, .DS_Store, .vscode, .idea) ao .gitignore do repositório para proteger colaboradores menos experientes e reduzir atritos na revisão.
  • Tensão observada: política estrita de “apenas do projeto” vs. prevenção pragmática de erros recorrentes; preocupação de que os ficheiros .gitignore acumulem “lixo” específico de IDE e plataforma.

Diretórios locais de rascunho / “attic”

  • Vários padrões para áreas locais de lixo:
    • Um nome de diretório globalmente ignorado como attic, aux ou scratch/.
    • .gitignore por diretório com * para que o diretório e todo o seu conteúdo (incluindo o próprio ficheiro de ignore) sejam ignorados.
  • São usados para notas pessoais, experiências ou ficheiros de editor/projeto que nunca devem ser commitados.

Ergonomia, complexidade e descoberta no Git

  • Alguns veem o artigo como uma ligeira repetição da documentação oficial; outros dizem que revelou funcionalidades que “sempre quiseram” mas nunca souberam que existiam.
  • O Git é descrito ao mesmo tempo como “belamente versátil” e suficientemente confuso para que os utilizadores nem sempre consigam prever os efeitos dos comandos.
  • A descoberta é um tema recorrente: o Git muitas vezes pode fazer o que as pessoas querem; a parte difícil é aprender a invocação certa.

Para além dos ignores: ferramentas e truques relacionados

  • .gitattributes é mencionado para tratar alguns ficheiros como “diff-ignored” (ou com estratégias de merge personalizadas), especialmente ficheiros de lock grandes, embora outros argumentem que estes diffs são importantes para segurança e auditoria de dependências.
  • Hooks via um diretório global de hooks podem bloquear ficheiros binários ou grandes, ou impor políticas sobre ficheiros de lock.
  • git update-index --assume-unchanged / --skip-worktree (muitas vezes como aliases) são usados para modificar localmente ficheiros rastreados sem mostrar alterações, embora sejam fáceis de esquecer.
  • includeIf na configuração do Git permite configuração por diretório ou por remoto (por exemplo, emails diferentes por empresa).