Gere um modelo .gitignore para sua stack de desenvolvimento

Selecione as tecnologias e os sistemas operacionais usados no seu repositório, e este gerador combinará os padrões de exclusão em um único arquivo determinístico. Stacks repetidas e padrões sobrepostos são removidos, preservando a primeira ordem útil. Nomes desconhecidos produzem um erro claro, evitando uma configuração incompleta em scripts, modelos de projeto e novos repositórios.

Selecione cada stack que cria artefatos locais

Comece pelas linguagens, runtimes, ferramentas de edição e sistemas operacionais que realmente participam do repositório. Um projeto Node desenvolvido no macOS pode precisar dos dois conjuntos, enquanto um backend misto pode combinar node, python e java. Incluir cada stack relevante é importante porque os artefatos não vêm apenas da linguagem principal: gerenciadores de pacotes criam caches, ferramentas de teste geram relatórios de cobertura, editores armazenam metadados do projeto e sistemas desktop adicionam registros ao sistema de arquivos. O gerador ignora diferenças entre maiúsculas e minúsculas e remove espaços externos, portanto Node e node selecionam a mesma entrada. Repetir uma stack não repete suas regras. Um nome desconhecido é rejeitado explicitamente, impedindo que um erro de digitação produza um arquivo aparentemente completo, mas sem toda uma cadeia de ferramentas. Mantenha a seleção vinculada às ferramentas que seus colaboradores usam; ecossistemas irrelevantes podem esconder arquivos que deveriam ser versionados.

Entenda a combinação e a remoção de duplicações

Os catálogos selecionados são processados na ordem informada. Dentro de cada catálogo, os padrões consolidados mantêm a ordem publicada. Quando o mesmo padrão exato aparece novamente, somente a primeira ocorrência permanece. Diretórios de compilação ou cobertura, por exemplo, são comuns a vários ecossistemas, mas o arquivo gerado contém cada regra coincidente apenas uma vez. Essa deduplicação por linha exata é propositalmente conservadora: dois padrões parecidos podem ter semânticas diferentes no Git, principalmente quando um deles é ancorado, usa curinga ou restaura um arquivo com ponto de exclamação. Por isso, o gerador não reescreve, amplia, ordena nem tenta simplificar regras. A decisão mantém um comportamento previsível e evita alterar o significado de um modelo padrão apenas para encurtá-lo. A resposta inclui a lista normalizada de stacks, o total final de padrões únicos e o texto completo com quebra de linha final, permitindo inspeção, gravação direta ou comparação confiável em testes automatizados.

Revise o resultado antes de adotá-lo

Considere o .gitignore gerado uma base sólida, e não um substituto para o conhecimento do repositório. Leia o resultado antes de fazer commit, principalmente as regras para arquivos de lock, diretórios de build, variáveis de ambiente, configurações do editor e código de fornecedores. Algumas equipes versionam intencionalmente arquivos que outros projetos ignoram; aplicações Rust costumam registrar Cargo.lock, por exemplo, enquanto bibliotecas podem seguir outra política. Acrescente regras específicas depois do bloco gerado e remova qualquer regra padrão incompatível com sua política de publicação ou reprodutibilidade. Se um arquivo já estiver rastreado, adicioná-lo ao .gitignore não o remove do índice nem do histórico do Git; trate essa migração separadamente e com cuidado. Como a geração é determinística e não usa rede, a mesma lista ordenada sempre retorna o mesmo texto. Assim, você pode usar a ferramenta em scripts de scaffolding, guardar as entradas escolhidas e revisar as diferenças quando o catálogo mudar.