Testador de .gitignore

Como usar

1. Cole seu .gitignore no primeiro campo exatamente como está no disco: comentários, linhas em branco, quebras CRLF e a marca BOM são tratados como o git os trata.
2. Escreva no segundo campo os caminhos que quer testar, um por linha e relativos à raiz do repositório. Termine a linha com barra para dizer que é um diretório: regras como `logs/` dependem disso.
3. Leia a tabela. Cada linha traz o veredito, o número da linha que decidiu e o texto da regra — os mesmos três dados que `git check-ignore -v` imprime, mais o pai excluído quando houver.
4. Confira o aviso âmbar. Ele aparece quando uma regra `!` casa com um caminho mas não pode ter efeito porque um diretório pai já está excluído, o motivo mais comum de uma negação parecer certa e não fazer nada.
5. Veja a lista de regras mortas no fim: as que não casaram com nenhum caminho colado. Com uma lista de caminhos representativa, são as linhas que vale a pena apagar.

Perguntas frequentes

Por que minha regra ! não traz o arquivo de volta?

Porque o git nunca chegou a olhar o arquivo. Ao percorrer a árvore e descobrir que um diretório está excluído, ele para ali e não desce, então nenhuma regra sobre algo lá dentro chega a ser avaliada; a documentação diz isso sem rodeios: não é possível reincluir um arquivo se um diretório pai dele estiver excluído. Com `logs/` e `!logs/important.log`, o log continua ignorado, e esta ferramenta mostra que a decisão veio da regra do diretório. A correção é excluir o conteúdo em vez do diretório: `logs/*` seguido de `!logs/important.log` funciona, porque `logs/*` casa com o que está dentro sem excluir logs. Para uma subárvore inteira a receita é `/logs/**`, depois `!/logs/keep/` e depois `!/logs/keep/**`.

Qual é a diferença entre build e /build?

Um padrão sem nenhuma barra é comparado com o nome base de cada caminho, em qualquer profundidade, então `build` ignora igualmente /build, /src/build e /a/b/c/build. Assim que o padrão contém uma barra que não seja o último caractere, ele fica ancorado ao diretório que contém o .gitignore, e `/build` e `docs/output` só casam daquela raiz para baixo. É por isso que um `node_modules` solto no .gitignore da raiz também esconde o node_modules de um pacote aninhado: costuma ser o que as pessoas querem, mas raramente o que escreveram de propósito. A barra inicial é o jeito de dizer «só aqui».

`logs/` casa com um arquivo chamado logs?

Não. Uma barra final significa que o padrão só casa com diretórios, então um arquivo comum chamado logs fica em paz enquanto um diretório logs, em qualquer profundidade, é ignorado junto com tudo o que há dentro. Isso importa aqui porque uma lista colada de caminhos não carrega informação de tipo: o git decide olhando o sistema de arquivos real e a esta ferramenta é preciso avisar. Escreva `logs/` para o diretório e `logs` para o arquivo; a mesma string com e sem barra pode receber vereditos opostos, e isso não é uma esquisitice da ferramenta, é a razão de `git check-ignore` surpreender quando o caminho ainda não existe.

O que as três formas de ** realmente significam?

Um `**` só tem sentido especial quando ocupa um segmento inteiro do caminho. `**/foo` no começo casa com foo em qualquer profundidade e é a forma explícita do que um padrão sem barras já faz. Um `foo/**` no fim casa com tudo o que está dentro de foo, mas não com o próprio foo, que é justamente por que a receita de reinclusão funciona. E `a/**/b` no meio casa com a/b, a/x/b e a/x/y/b, ou seja, com zero ou mais diretórios. Em qualquer outra posição são asteriscos comuns: `a**b` é o mesmo que `a*b`, e um `*` sozinho nunca atravessa uma barra, então `src/*.c` casa com src/main.c mas não com src/lib/main.c.

A regra parece certa, mas o git continua mostrando o arquivo como modificado.

O .gitignore só vale para arquivos que o git ainda não rastreia. Depois que um arquivo foi comitado, acrescentar um padrão não muda nada: o git continua relatando suas mudanças e continua comitando. Pare de rastreá-lo primeiro com `git rm --cached caminho` (que mantém a cópia de trabalho) e comite essa remoção; do commit seguinte em diante quem manda é a regra de ignorar. Esta ferramenta responde à pergunta sobre arquivos não rastreados, a mesma que o `check-ignore` responde, então um caminho que aqui aparece como ignorado ainda pode surgir no `git status` se estiver no índice — e é a primeira coisa a conferir quando os dois discordam.

Qual .gitignore vence quando há vários?

O git lê várias fontes em uma ordem fixa e vence a mais específica: os padrões da linha de comando, depois os arquivos .gitignore, em que um de um diretório mais profundo se sobrepõe ao de cima, depois o .git/info/exclude para regras locais do repositório que não são compartilhadas e, por fim, o arquivo global apontado por core.excludesFile. Dentro de um mesmo arquivo decide a última linha que casa. Esta ferramenta modela um único .gitignore, então se o veredito dela não bater com o seu repositório, o provável culpado é um .gitignore aninhado, uma entrada do info/exclude ou o seu arquivo global: rode `git check-ignore -v` lá e a coluna de origem dirá qual arquivo foi.

Ferramentas relacionadas