Como usar .gitignore e evitar enviar segredos para o GitHub

Publicado em 2026-10-26 por frfrand

Padrões gitignore, arquivos já versionados e rotação de segredos

Como usar .gitignore e evitar enviar segredos para o GitHub

Subiu um projeto ao GitHub e descobriu que também enviou .env, arquivos temporários e uma pasta gigante de dependências. .gitignore evita que o Git comece a rastrear certos arquivos, mas tem uma limitação importante: não apaga o que já foi publicado.

A ideia é usá-lo para resolver um problema de verdade, não memorizar comandos porque ficam bem em uma captura. Vamos com o essencial, um exemplo de trabalho e os erros que mais convém evitar.

O que o .gitignore faz e quando serve

Os padrões são aplicados normalmente a arquivos não rastreados. Um arquivo versionado antes de ser adicionado ao .gitignore continuará sendo rastreado. Para deixar de incluí-lo em commits futuros, você pode removê-lo do índice, mas se ele continha um segredo, a credencial já está comprometida e deve ser rotacionada.

Se você está aprendendo, teste primeiro em um repositório ou ambiente de teste. Se administra produção, documente o estado antes de executar qualquer coisa que altere arquivos, histórico ou dados. Isso permite entender o que mudou e recuperar-se se errar.

Exemplo para copiar e entender

# Ejemplo .gitignore
.env
.env.*
!.env.example
node_modules/
__pycache__/
*.pyc

# Si .env ya estaba versionado
git rm --cached .env
git commit -m 'dejar de versionar entorno'

Não copie o comando final sem olhar o estado anterior. Os nomes de branch, host, usuário ou caminhos são exemplos; substitua-os pelos do seu projeto. Alguns comandos modificam arquivos ou fazem requisições que podem gravar dados.

Como eu usaria passo a passo

Passo 1. Identifique o que seu projeto gera e o que outro desenvolvedor realmente precisa.
Passo 2. Adicione padrões para arquivos temporais e segredos; deixe um .env.example sem valores privados.
Passo 3. Verifique por que um caminho está sendo ignorado com git check-ignore -v caminho.
Passo 4. Se já houver credenciais em commits, revogue-as e substitua-as imediatamente.
Passo 5. Utilize um gerenciador de segredos para implantações e um scanner de vazamentos em CI quando possível.

Pare após cada passo e verifique o resultado. Se algo falhar, anote a mensagem exata antes de mudar de estratégia. Pular entre cinco soluções aleatórias costuma dificultar encontrar a causa real.

Um caso que pode acontecer com clientes

Um bot que consulta uma API de IA precisa de uma chave do provedor. O repositório deve conter como configurar AI_API_KEY, não o valor real. O aplicativo recebe a credencial do ambiente ao ser executado.

O objetivo não é que «funcione uma vez», mas que você possa explicar como repeti-lo sem comprometer outro aplicativo. Se houver dados ou credenciais de clientes, trabalhe com testes separados e acessos mínimos.

O erro que mais vejo

git rm --cached não remove o segredo do histórico remoto nem de clones antigos. Para uma chave vazada, rotacionar e revisar acessos é urgente; limpar o histórico pode ser adicional, mas não substitui essa medida.

Uma regra simples: se você não puder explicar o que o comando fará no seu código ou servidor, consulte primeiro a ajuda oficial. Assim, você evita confundir uma solução rápida com um novo problema.

Onde entra o ArduMaker?

Ao fazer deploy a partir do Git no ArduMaker, prepare variáveis seguras no ambiente de execução e não insira senhas dentro do frontend. Separe os acessos por cliente e por serviço.

Por exemplo, você pode fazer deploy de um repositório Git para um VPS, associar um domínio HTTPS e gerenciar serviços e bancos de dados a partir do mesmo ambiente. O painel reduz tarefas repetitivas de infraestrutura, mas não substitui o Git, os testes nem a revisão de permissões do projeto.

Perguntas rápidas antes de aplicá-lo

Isso altera a produção? Depende de onde você executa a ação. Teste localmente primeiro, identifique o commit ou serviço afetado e prepare um plano de recuperação.

Como comprovar que deu certo? Não fique apenas com a ausência de mensagens de erro: revise o status, execute um teste funcional e verifique os logs ou o histórico correspondente.

Vale a pena automatizar? Se for repetível e tiver resultados verificáveis, sim. Mas a automação deve falhar de forma clara e não esconder erros ou credenciais.

Para ampliar

Resumo: a ferramenta útil não é a que tem mais opções, mas sim a que permite entender o que mudou, comprovar isso e continuar trabalhando sem surpresas.