Passo 1 de 7
Escolher o que deve ficar fora do histórico
Distinguir arquivos necessários ao projeto de arquivos descartáveis ou específicos de uma máquina.
Trilha de aprendizado · Nível 1 · Tutorial 5
Você será capaz de definir quais arquivos locais devem ficar fora do versionamento, verificar as regras de exclusão e reconhecer os limites do .gitignore na proteção de credenciais.
Escolher o que deve ficar fora do histórico
Distinguir arquivos necessários ao projeto de arquivos descartáveis ou específicos de uma máquina. 2 min
Criar regras no .gitignore
Crie o arquivo no lugar certo e escreva regras por nome, extensão e pasta, considerando também as subpastas. 3 min
Conferir o efeito com git status
Compare o status antes e depois de salvar as regras e confira quais arquivos continuam disponíveis para versionamento. 2 min
Versionar o próprio .gitignore
Prepare, confira e registre o .gitignore para incluir as regras no histórico do projeto. 2 min
Entender os limites das regras
Preveja o efeito de uma nova regra sobre arquivos não rastreados, já preparados e presentes no histórico. 2 min
Manter credenciais fora dos commits
Diferencie a prevenção de commits com credenciais da resposta necessária quando uma credencial já foi exposta. 2 min
Aplicar as regras e concluir
Resolva um miniprojeto: escreva regras, confira o resultado esperado e decida como agir diante de uma credencial exposta. 3 min
Passo 1 de 7
Distinguir arquivos necessários ao projeto de arquivos descartáveis ou específicos de uma máquina.
Antes de preparar um commit, pergunte: este arquivo é necessário para compreender, executar ou manter o projeto? Código e instruções costumam fazer parte do histórico. Arquivos descartáveis ou específicos do seu computador são candidatos a ficar fora.
Exemplo
Considere a função descrita de cada arquivo deste projeto fictício.
Toque em um item e depois no par correspondente.
Uma configuração usada por toda a equipe pode ser essencial ao projeto. Já preferências pessoais do editor ou caminhos que só existem no seu computador costumam ficar fora do histórico.
Dica
Ser gerado automaticamente não basta para excluir um arquivo. Se ele precisa acompanhar cada versão do projeto, pode ser necessário registrá-lo.
Um projeto tem três arquivos novos:
Passo 2 de 7
Crie o arquivo no lugar certo e escreva regras por nome, extensão e pasta, considerando também as subpastas.
Na raiz do projeto — a pasta principal — crie um arquivo de texto chamado exatamente .gitignore. Ele deve ficar fora da pasta interna .git, e não pode ter .txt no final do nome.
Escreva um padrão por linha, como neste exemplo:
config.local.json
*.log
cache/config.local.json corresponde a esse nome, sem incluir todo arquivo .json.*.log usa o curinga * para corresponder a nomes que terminam em .log.cache/ usa a barra final para indicar uma pasta chamada cache e seu conteúdo.O arquivo pessoal é ajustes.local.json; o compartilhado é ajustes.json. Use o nome exato para excluir apenas o pessoal:
____
Use o curinga * para corresponder aos nomes que terminam em .log:
____
Indique a pasta cache e seu conteúdo, usando a barra final:
____
Com o .gitignore na raiz, os três padrões apresentados também podem corresponder a nomes dentro de subpastas do projeto.
Exemplo
config.local.json corresponde tanto a config.local.json quanto a ambiente/config.local.json.*.log corresponde tanto a execucao.log quanto a logs/execucao.log.cache/ corresponde tanto à pasta cache/ quanto à pasta src/cache/, incluindo o conteúdo de cada uma.O .gitignore na raiz contém config.local.json, *.log e cache/, uma regra por linha. Qual arquivo NÃO corresponde a nenhuma dessas regras?
Passo 3 de 7
Compare o status antes e depois de salvar as regras e confira quais arquivos continuam disponíveis para versionamento.
Depois de salvar o .gitignore, execute git status na pasta do projeto. Os arquivos não rastreados que correspondem às regras deixam de aparecer na saída padrão do comando.
Exemplo
Queremos manter README.md e app.py disponíveis para versionamento. Já config.local.json, app.log e os arquivos temporários de cache/ devem ficar de fora.
config.local.json
*.log
cache/Todos os arquivos listados inicialmente são não rastreados. Entre as duas execuções de git status, a única mudança foi criar e salvar o .gitignore com as regras apresentadas. Veja os trechos simplificados:
Arquivos não rastreados:
README.md
app.log
app.py
cache/
config.local.jsonArquivos não rastreados:
.gitignore
README.md
app.pyJustifique sua resposta: o que deixou de aparecer na listagem e quais arquivos estão disponíveis para versionamento depois?
Escreva pelo menos 20 caracteres (0/20).
Dica
app.log, config.local.json e o conteúdo de cache/ continuam no disco. As regras apenas fizeram esses arquivos não rastreados deixarem de aparecer na saída padrão do git status.
Neste exemplo, ver o próprio .gitignore entre os não rastreados é esperado: ele está disponível para ser registrado. A conferência está completa quando os arquivos locais pretendidos ficam fora da listagem e os arquivos necessários continuam nela.
Passo 4 de 7
Prepare, confira e registre o .gitignore para incluir as regras no histórico do projeto.
O .gitignore normalmente deve ser versionado: ele registra quais arquivos devem ficar fora dos commits.
Salvar o arquivo faz as regras valerem localmente. Preparar e fazer o commit registra essas regras no histórico do projeto.
As regras do .gitignore só começam a valer depois que você faz o commit desse arquivo.
Use o fluxo que você já conhece. Neste exemplo, as exclusões já foram conferidas e não há outros arquivos preparados. O objetivo é registrar somente o .gitignore.
Na raiz do projeto, execute:
git add .gitignore
git diff --stagedO diff deve mostrar apenas o .gitignore, com as regras pretendidas, como config.local.json, *.log e cache/.
Essas linhas são regras, não o conteúdo dos arquivos ignorados. Se aparecerem outros arquivos ou regras inesperadas, revise a preparação antes de continuar.
git commit -m "Adiciona regras para ignorar arquivos locais"Você preparou apenas o .gitignore. Na conferência, o diff mostra +*.log como uma linha adicionada a esse arquivo. O que essa linha leva para o commit?
Passo 5 de 7
Preveja o efeito de uma nova regra sobre arquivos não rastreados, já preparados e presentes no histórico.
Adicionar uma regra ao .gitignore não faz o Git parar de rastrear um arquivo.
Isso vale também para um arquivo novo que você já adicionou à área de preparação: ele continua preparado, mesmo que você salve uma regra correspondente depois.
Exemplo
Você já versionou config.local.json. Depois, adicionou esse nome ao .gitignore e editou o arquivo.
O git status continua mostrando a modificação. Isso não significa que a regra esteja escrita incorretamente: ela não interrompe o rastreamento existente.
Você acabou de salvar *.log no .gitignore da raiz. Sem fazer nenhuma outra alteração, associe cada situação ao resultado.
Toque em um item e depois no par correspondente.
Salvar ou fazer commit do .gitignore não modifica commits anteriores nem apaga versões antigas de arquivos.
Se um arquivo já entrou em um commit, adicionar uma regra correspondente depois não remove aquela versão do histórico. O commit do .gitignore registra as regras, mas não altera o passado.
Ontem, execucao.log entrou em um commit. Hoje, você salvou e versionou a regra *.log no .gitignore. A versão de execucao.log registrada ontem continua naquele commit.
Passo 6 de 7
Diferencie a prevenção de commits com credenciais da resposta necessária quando uma credencial já foi exposta.
Senhas, tokens e chaves privadas são credenciais de acesso e não devem entrar em commits. Regras para arquivos locais sensíveis ajudam na prevenção, mas o .gitignore não é um cofre nem uma garantia de segurança.
Dica
Antes de usar git add, examine o conteúdo dos arquivos escolhidos, inclusive os novos. Antes do commit, confira o conteúdo preparado com git diff --staged. Se encontrar uma credencial, interrompa o commit e corrija o conteúdo que será registrado.
Nesta prática, não use credenciais reais.
Depois de ignorar o arquivo local que guarda meu token, posso dispensar a revisão do conteúdo preparado antes do commit.
Providencie imediatamente a revogação ou a substituição da credencial exposta junto ao serviço responsável. Revogar significa invalidar a credencial. Se houver substituição, garanta que a antiga deixe de funcionar: criar uma nova e manter a antiga ativa não resolve a exposição.
Atenção
Adicionar uma regra ao .gitignore ou apagar a credencial da versão atual não neutraliza uma exposição anterior. Os commits antigos não são alterados por essas ações, e alguém pode ter copiado a credencial.
Em um cenário fictício, um token entrou em um commit visto por outras pessoas. Você removeu o token da versão atual e adicionou uma regra ao .gitignore. Qual ação ainda é necessária?
Passo 7 de 7
Resolva um miniprojeto: escreva regras, confira o resultado esperado e decida como agir diante de uma credencial exposta.
Neste repositório fictício, todos os arquivos abaixo ainda estão não rastreados e nada está preparado. O .gitignore ainda não existe, e não há outras regras de exclusão. Use a função de cada arquivo para decidir o que deve ficar fora do histórico.
miniprojeto/
├── README.md — instruções do projeto
├── app.js — código-fonte
├── config.shared.json — configuração necessária para todos
├── config.local.json — preferências desta máquina
├── debug.log — log descartável de execução
└── cache/
└── resultado.tmp — cache que pode ser recriadoPara o miniprojeto da tela anterior:
.gitignore na raiz: uma por nome, uma para a extensão dos logs e uma por pasta.git status após salvar as regras, antes de preparar qualquer arquivo..gitignore em um commit.Escreva pelo menos 30 caracteres (0/30).
Agora imagine que config.local.json já estava em um commit e continha um token que foi exposto. Qual avaliação está correta?
Resumo
Parabéns! Você concluiu: Evitar arquivos desnecessários nos commits com .gitignore
Use esse checklist para manter seus próximos commits focados no que o projeto precisa, sem tratar o .gitignore como garantia de segurança.
Você concluiu este nível!
Agora você vai iniciar: Branches e integração de alterações
Criar e alternar branches com segurançaCriar uma linha de trabalho separada, registrar mudanças nela e alternar entre branches sem descartar alterações pendentes.Milhares de cursos online em vídeo, ebooks e áudiobooks.
Para testar seus conhecimentos no decorrer dos cursos online
Gerado diretamente na galeria de fotos do seu celular e enviado ao seu e-mail
Baixe nosso aplicativo pelo QR Code ou pelos links abaixo:.
Leve o conhecimento no seu bolso.
Baixe o aplicativo Cursa.
São centenas de Cursos gratuitos a disposição, com Certificado de conclusão gratuito que é salvo em sua galeria de imagens do celular.
Baixe o app para ter acesso ao Certificado de conclusão de Curso Gratuitamente.
+ de 10 milhões
de alunos
Certificado grátis e
válido em todo o Brasil
60 mil exercícios
gratuitos
4,8/5 classificação
nas lojas de apps
Cursos gratuitos em
vídeo, ebooks e audiobooks