Testador de Gitignore
Cole as suas regras do .gitignore e uma lista de caminhos de ficheiros e veja exatamente que ficheiros são ignorados, por que regra e linha exatas, e que regras de negação são silenciosamente ignoradas porque uma diretoria mãe já está a ser ignorada.
🔒 Processado inteiramente em seu navegador – nada que você digita aqui é carregado.
Resultado
"Porque é que a minha negação no .gitignore não funciona?" é uma das perguntas mais comuns sobre git, e a resposta honesta é quase sempre a mesma: um padrão `!` a tentar voltar a incluir um ficheiro dentro de uma diretoria que uma regra anterior já exclui nunca pode funcionar, porque o git não desce a diretorias ignoradas para reavaliar o que está lá dentro. Esta ferramenta reimplementa o verdadeiro algoritmo de correspondência do .gitignore do git — não uma aproximação —, para poder detetar e explicar precisamente essa situação, além de todas as outras regras de padrões que o git suporta.
Cole as suas regras do .gitignore numa caixa e uma lista de caminhos de ficheiros (um por linha, como `dist/index.js`, `node_modules/foo/bar.js`, ou `.env`) na outra, e a ferramenta avalia cada caminho exatamente como o git faria: comentários e linhas em branco são ignorados, espaços finais são removidos exceto se escapados, um `!` inicial nega uma regra, uma `/` inicial ancora-a à raiz em vez de a deixar corresponder a qualquer profundidade, uma `/` final restringe-a a diretorias, e `*`, `?`, classes de caracteres `[abc]` e `**` (que corresponde cruzando fronteiras de diretorias) funcionam todos conforme as regras de glob documentadas.
Crucialmente, os caminhos são verificados diretoria a diretoria da raiz para baixo, tal como o motor de ignore do próprio git funciona — e não testando o caminho completo contra cada regra de forma isolada. É isso que permite detetar corretamente o caso da negação ineficaz: se `dist/` for ignorado na linha 3 e um `!dist/keep.js` posterior tentar salvar um ficheiro dentro dela, esta ferramenta reporta `dist/keep.js` como continuando ignorado, identifica a regra da linha 3 como a razão, e assinala separadamente a negação como anulada, em vez de silenciosamente fingir que funcionou.
A tabela de resultados dá a cada caminho testado uma linha própria com um veredito claro de ignorado ou não, o texto exato da regra e o número da linha que o decidiram e — sempre que relevante — uma nota em linguagem simples que explica uma negação anulada ou uma regra herdada de uma diretoria mãe. É este o detalhe que transforma um .gitignore confuso em algo que consegue realmente compreender antes de fazer commit.