block Gerador de .gitignore star

Como Funciona

Marque as caixas que correspondem ao seu projeto — uma linguagem ou ambiente de execução como Node.js, Python ou Java, um sistema operacional como macOS, Windows ou Linux, um editor como VS Code ou IntelliJ/JetBrains, além de um bloco para os próprios arquivos residuais do Git e outro para .env e segredos. Cada caixa adiciona um pequeno conjunto de padrões de exclusão bem estabelecidos, extraídos das convenções que a comunidade realmente utiliza — node_modules/ para Node, __pycache__/ e .venv/ para Python, *.class e target/ para Java, .DS_Store para macOS, Thumbs.db para Windows, e assim por diante. À medida que você marca mais caixas, a ferramenta combina tudo em uma única lista, remove duplicatas exatas e mostra o resultado ao vivo em uma caixa de texto que pode ser copiada ou baixada diretamente como um arquivo chamado .gitignore.

O motivo para combinar categorias em vez de escrever uma do zero é que a maioria dos projetos reais se encaixa em várias categorias ao mesmo tempo: uma API Node.js desenvolvida em um Mac com VS Code precisa do bloco Node para os artefatos de build, do bloco macOS para que o .DS_Store nunca acabe em um pull request, e do bloco VS Code para que suas configurações pessoais de editor não sobrescrevam as de um colega de equipe. Marcar os três e baixar de uma só vez é mais rápido e menos sujeito a erros do que reunir padrões de memória ou copiar e colar fragmentos de projetos antigos.

Bom Saber

Um arquivo .gitignore afeta apenas os arquivos que o Git ainda não conhece — ele diz ao Git quais arquivos não rastreados devem ficar de fora do git status, do git add . e dos commits futuros. Ele não tem nenhum efeito sobre arquivos que já estão rastreados (já commitados pelo menos uma vez). Esse é o ponto de confusão mais comum: adicionar .env ao .gitignore depois que ele já foi commitado não o remove do repositório nem impede que o Git continue rastreando suas alterações futuras. Para realmente parar de rastrear um arquivo, primeiro é preciso executar git rm --cached <arquivo> (o que o remove do índice do Git, mas o mantém no disco), commitar essa remoção — só então a regra correspondente do .gitignore passa a valer dali em diante.

A maioria dos padrões oferecidos aqui vem do repositório oficial github/gitignore do GitHub, a fonte mais referenciada para templates específicos de linguagens e ferramentas, e a mesma coleção que o próprio GitHub oferece quando você cria um novo repositório pela interface web. Manter pastas de dependências como node_modules/ e saídas de build como dist/ ou target/ fora do controle de versão importa pelo tamanho — essas pastas podem facilmente pesar muitas vezes mais que o seu código-fonte real e são regeneradas trivialmente a partir de um lockfile ou script de build — enquanto manter arquivos como .env, *.pem e *.key de fora importa pela segurança: commitar um segredo no histórico do Git o torna efetivamente público para sempre, já que removê-lo do commit mais recente não o apaga dos commits anteriores sem reescrever todo o histórico.