Testador de padrões .gitignore｜Veja qual regra decide cada caminho

Cole suas regras de .gitignore e uma lista de caminhos, e a ferramenta mostra para cada caminho Ignorado ou Mantido, junto da regra exata (e do número da linha) que produziu a decisão. Feito para verificar cadeias de negação como *.log + !important.log, padrões só-diretório como node_modules/ e globs recursivos **/ antes de commitar uma edição no .gitignore.

💡 Sobre esta ferramenta

Um arquivo .gitignore esconde várias armadilhas que aparecem tarde: a ordem das regras decide o resultado (vence a última correspondência, não a primeira), a barra final muda o significado do padrão, e os globs **/ podem capturar amplo ou estreito demais dependendo do que vem depois. Rodar git check-ignore -v caminho a caminho funciona quando você já sabe qual arquivo investigar, mas vira um trabalho chato após editar um .gitignore de 50 linhas e querer ver todas as consequências lado a lado.

Este testador pega o conjunto completo de regras à esquerda e a lista de caminhos à direita, e renderiza cada decisão junto da regra que a produziu. Regras negadas recebem a marca [negado], regras só-diretório só correspondem a caminhos tipo pasta, e padrões inválidos aparecem em uma barra vermelha no topo do resultado sem interromper a avaliação do restante.

🧐 Perguntas frequentes

P. A precedência segue a do git? R. Sim — as regras são avaliadas de cima para baixo e vence a última correspondência. *.log seguido de !important.log mantém important.log; na ordem inversa, ele é ignorado.

P. Como funciona o padrão só-diretório (node_modules/)? R. Padrões terminados em / só correspondem a caminhos tipo pasta. Um arquivo chamado node_modules (sem barra final) não entra. Um caminho como node_modules/lodash/index.js aparece como ignorado com a linha da regra mostrada.

P. Como se comportam os globs **/? R. **/foo corresponde a foo em qualquer profundidade, foo/** a tudo abaixo de foo/. A especificação está em gitignore(5). Teste **/build/ com a/build/x e a/b/build/y para confirmar.

P. E se um padrão tiver erro? R. Padrões inválidos ([ sem fechar, escapes mal formados) aparecem em uma barra vermelha no topo do resultado. A avaliação continua para as regras restantes.

P. Posso testar vários arquivos .gitignore ao mesmo tempo? R. O testador avalia um único conjunto combinado. Se você tem um .gitignore na raiz e outro em uma subpasta, cole-os juntos na ordem raiz → subpasta; as regras mais locais ganham porque são avaliadas por último.

P. Por que um caminho com / inicial não corresponde? R. As barras / e ./ no início do caminho são normalizadas e removidas. Para fixar à raiz do repositório, escreva / do lado do padrão (por exemplo /dist/).

📚 Curiosidades sobre .gitignore

O arquivo .gitignore existe no git desde 2005, mas a gramática canônica vive na página de manual gitignore(5), não nos READMEs. Uma sutileza que pega até quem já tem experiência: quando um diretório pai está ignorado, nenhuma regra !pai/filho colocada lá dentro consegue re-incluir o arquivo. Por isso o repositório oficial github/gitignore, que mantém templates para Node, Python, Java, Unity e muitos outros ecossistemas, mantém as negações próximas das regras que pretendem anular, e nunca dentro de uma pasta já excluída.

Outra armadilha frequente em discussões em português é que o git usa last-match-wins, não first-match-wins. Quem copia um template do github/gitignore e adiciona suas próprias regras no final pode acidentalmente re-ignorar algo que o template já tinha tirado da lista mais acima. Passar o conjunto de regras e um lote de caminhos por este testador antes do commit deixa essa cadeia de override visível — cada linha de resultado mostra exatamente qual regra decidiu o veredito, dispensando rodar git check-ignore arquivo por arquivo.