Ignorando arquivos e boas práticas
Você clona um projeto chamado weather-app, executa npm install e verifica o status do seu novo repositório.
$ git status
Untracked files:
(use "git add <file>..." to include in what will be committed)
node_modules/
dist/
.envTrês pastas e arquivos aparecem como não rastreados, e nenhum deles deve estar em um commit. node_modules/ é milhares de arquivos que npm install regenera a partir de package.json em segundos. dist/ é saída de build que é reconstruída a partir do seu código-fonte toda vez. E .env contém uma chave de API. Nada disso deveria nunca chegar no histórico do seu projeto, e digitar git add . sem pensar é exatamente como acontece.
Dizendo ao Git o que ignorar
Um arquivo .gitignore lista padrões para arquivos e pastas que Git nunca deve rastrear. Você o cria uma única vez na raiz do seu projeto, o mesmo lugar onde você executou git init quando configurou o repositório em Seu primeiro repositório, e a partir daí, git status e git add . silenciosamente pulam tudo que corresponde.
# .gitignore
node_modules/
dist/
.envCada linha é um padrão: um nome de pasta simples como dist/ ignora toda essa pasta, onde quer que apareça no projeto. Faça commit do próprio arquivo .gitignore. Ele é pequeno, é útil para todos que clonam o projeto, e deve estar no histórico da mesma forma que seu código-fonte.
$ git status
On branch main
nothing to commit, working tree cleanCom os padrões no lugar, git status fica silencioso. Esse é exatamente o ponto: as pastas e arquivos que você nunca quer fazer commit param de aparecer como ruído, então as coisas que aparecem são as que realmente importam.
.gitignore lista o que Git nunca deve rastrear: node_modules/, dist/, e .env são os suspeitos usuais em quase qualquer projeto. Faça commit do próprio arquivo .gitignore para que todos que clonam o projeto obtenham o mesmo status limpo. Uma vez perdi uma tarde inteira fazendo stage de milhares de arquivos de dependência por acidente antes de aprender isso. Nunca faça commit de secrets
Uma chave de API, uma senha de banco de dados, ou um certificado de assinatura nunca devem aparecer em um commit. Isso vale para um repositório privado tão firmemente quanto um público, e vale a partir do primeiro commit em diante. Coloque secrets em um arquivo como .env, adicione esse arquivo ao .gitignore no primeiro dia, e carregue os valores em seu app a partir de lá em vez de escrevê-los em seus arquivos-fonte.
# .env
WEATHER_API_KEY=sk_live_9f8e7d6c5b4a# .gitignore
.envSiga essa regra automaticamente, sempre, sem exceções. Uma chave em um commit é acessível por qualquer pessoa com acesso ao repositório, e em um repositório público, por qualquer pessoa.
.env e adicione .env ao seu .gitignore antes de rodar git add. Essa é a única regra neste capítulo inteiro que merece ser tratada como absoluta. Adicionando um arquivo ao .gitignore depois que está rastreado
Essa é a armadilha que pega quase todos pelo menos uma vez. Você faz commit de um arquivo por acidente, percebe seu erro, adiciona ao .gitignore (a linha echo abaixo acrescenta o caminho a esse arquivo), e espera que Git esqueça dele. Não esquece.
$ git add config/settings.json
$ git commit -m "Add app settings"
# depois, você percebe que foi um erro
$ echo "config/settings.json" >> .gitignore
$ git status
On branch main
nothing to commit, working tree cleangit status mostra uma árvore limpa, mas config/settings.json ainda é rastreado e ainda aparece em todo git log futuro e em todo clone. Regras de ignore se aplicam apenas a arquivos que Git ainda não conhece. Uma vez que um arquivo foi adicionado e commitado, faz parte do seu histórico, e .gitignore não tem opinião sobre arquivos já naquele histórico.
Para realmente parar de rastreá-lo a partir de agora, diga ao Git para soltar o arquivo do que segue deixando o arquivo no seu disco:
$ git rm --cached config/settings.json
$ git commit -m "Stop tracking config/settings.json"git rm --cached <file> remove o arquivo do rastreamento do Git sem deletá-lo do seu diretório de trabalho. Faça commit dessa remoção, e a partir daí seu padrão .gitignore faz o trabalho que você queria que fizesse desde o começo.
.gitignore depois que Git já o rastreia não faz nada para esse arquivo. Regras de ignore se aplicam apenas a arquivos que Git nunca adicionou ainda. Para parar de rastrear um arquivo que escapou por acidente, execute git rm --cached <file> e faça commit dessa mudança. Boas práticas: commits pequenos e repositório limpo
Um .gitignore organizado é metade de manter um repositório que vale a pena trabalhar. A outra metade é como você molda seus commits. Faça cada commit uma mudança focada: uma correção de bug, uma pequena feature, um único refactor. Se uma tarde de trabalho toca várias coisas não relacionadas, divida em vários commits em vez de jogar tudo em um só no final do dia.
$ git add src/weather-widget.js
$ git commit -m "Fix temperature rounding in weather widget"Commits pequenos são mais fáceis de revisar, mais fáceis de reverter se algo quebrar, e mais fáceis de ler novamente seis meses depois quando você está tentando lembrar por que uma linha de código existe. O commit loop cobre o que torna uma mensagem de commit útil; esse hábito é sobre manter a mudança em si pequena o suficiente para que uma boa mensagem seja até possível de escrever.
.gitignore cobrindo as pastas e secrets que nunca devem ser rastreados. Esses dois hábitos juntos são a maior parte do que torna um repositório agradável de trabalhar. Pequenos hábitos, formados cedo, economizam muita limpeza depois.