Todo desenvolvedor já enviou arquivos com informações confidenciais para o repositório público por engano. Como lidar com esse problema? Como ter certeza de que nada assim acontecerá novamente?
Neste artigo, direi o que fazer se um arquivo acidentalmente entrar no repositório e não tiver absolutamente nada para fazer lá. Aqui irei fornecer comandos Git que permitirão a você corrigir o histórico e compartilhar algumas recomendações para organizar o trabalho seguro com informações confidenciais.
Removendo arquivos confidenciais do repositório Git ( imagem grande )
Minimizando danos
Então, você acidentalmente cometeu um arquivo com informações confidenciais. Vamos chamar esse arquivo
.env. Imediatamente depois que isso aconteceu, você precisa se perguntar algumas perguntas:
- O commit foi enviado para o repositório remoto?
- O repositório remoto está acessível publicamente?
▍Commit ainda não foi enviado para o repositório remoto
Se você ainda não enviou um commit para o repositório, então, em geral, a situação que surgiu não representa nenhuma ameaça. Para consertar tudo, você só precisa voltar ao commit anterior:
git reset HEAD^ --soft
Os arquivos permanecerão na cópia de trabalho do repositório, você pode fazer as alterações necessárias no projeto.
Se você deseja manter o commit e só precisa remover alguns arquivos dele, faça o seguinte:
git rm .env --cached
git commit --amend
Este parâmetro
--amendsó pode ser usado para trabalhar com o commit mais recente. Se você adicionou mais alguns após uma falha de confirmação, use este comando:
git rebase -i HEAD~{ ?}
Isso corrigirá o commit errado e ajudará você a não perder as mudanças feitas no projeto por outros commits.
▍ O compromisso foi enviado para o repositório remoto
Se você já enviou um commit para um repositório remoto, então, primeiro de tudo, você precisa saber sobre a diferença entre repositórios públicos e privados.
Se seu repositório é privado e não está acessível para bots ou pessoas em quem você não confia, você pode simplesmente ajustar o último commit usando alguns dos comandos acima.
Se você enviou outros commits para o repositório após um commit problemático, isso não impedirá que você remova arquivos confidenciais do seu histórico Git usando o comando git filter-branch ou a ferramenta BFG Repo-Cleaner .
Aqui está um exemplo de uso
git filter-branch:
git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all
Mas, ao fazer isso, tenha em mente dois aspectos importantes de tais mudanças feitas no repositório:
- Git. , - , , PR, . .
- . , , . , , , , . , ID, , .
Preciso criar novas chaves secretas se suas versões atuais estiverem no repositório público?
Se você responder brevemente à pergunta no título, então - é necessário. Se o seu repositório estiver disponível publicamente, ou se você, por qualquer motivo, acreditar que ele não é um lugar para armazenar dados confidenciais, você precisará considerar os dados confidenciais que entraram nele como comprometidos.
Mesmo se você removeu esses dados do repositório, você não pode fazer nada com bots e garfos de repositório. Como proceder?
- Desative todas as chaves ou senhas. Isso deve ser feito primeiro. Depois de desativar as chaves, as informações confidenciais que se tornaram públicas se tornam inúteis.
- Personalize o arquivo
.gitignore. Pegar os.gitignoreregistros de arquivos com informações confidenciais para o Git não monitoraria o status desses arquivos. - Prepare um commit que não contenha arquivos confidenciais.
- Envie as alterações para o repositório, forneça ao commit explicações sobre a situação. Não tente esconder o erro. Todos os programadores trabalhando no projeto, incluindo você, irão apreciar a presença no repositório de um commit com uma explicação da situação e com uma descrição do que exatamente foi corrigido com este commit.
Melhores práticas para manter arquivos confidenciais em projetos que usam Git para controle de versão
Para evitar vazamentos de informações confidenciais, você deve seguir as recomendações a seguir.
▍ Armazenar dados confidenciais em um arquivo .env (ou outro arquivo semelhante)
Mantenha as chaves de API e informações semelhantes em um único arquivo
.env. Com essa abordagem, se o Git não controlar o estado do arquivo .env, ao adicionar uma nova chave a esse arquivo, você não a enviará acidentalmente para o repositório.
Outra vantagem dessa abordagem é que assim você terá acesso a todas as chaves por meio de uma variável global
process.
▍ Use chaves de API, se possível
Chaves de API comprometidas são fáceis de desativar e recriar. Se possível - use-os, e não algo como logins e senhas.
▍Armazene chaves de API usando sua ferramenta de compilação
Geralmente, as chaves de API são necessárias ao criar aplicativos. Ferramentas de construção como o Netlify permitem que você mantenha as chaves em cofres seguros. Essas chaves são injetadas automaticamente no aplicativo usando uma variável global
process.
Gestão de Variáveis de Ambiente
▍ Adicione a entrada do arquivo .env ao arquivo .gitignore
Impedir que o Git rastreie arquivos confidenciais.
▍ Prepare um arquivo de template .env.template
Ter esse arquivo de modelo ajuda aqueles que trabalham em um projeto a adicionar chaves de API ao projeto, eliminando a necessidade de ler a documentação.
▍ Não altere o histórico do Git em repositórios remotos
Tente seguir esta regra estritamente. Se você seguiu as orientações acima, não precisará alterar seu histórico do Git.
Resultado
Espero que meu material ajude você a trabalhar com segurança com dados confidenciais.
Você já enviou algo para um repositório público que não deveria ir lá?
