Segurança com git
Alguns comandos git destroem trabalho que o git nem sempre consegue recuperar, ou pulam as verificações nas quais a equipe confia. Não os execute sem aprovação.
A regra de aprovação
Antes de executar um comando protegido, obtenha aprovação que atenda a todas estas condições:
- Ela vem do usuário, nesta conversa.
- É para este comando neste destino, e você mostrou o comando exato primeiro.
- Ela vem depois de você ter dito o que o comando destrói.
Isto não é aprovação:
- Uma aprovação para uma execução anterior do mesmo comando. Cada execução precisa de sua própria aprovação.
- Uma mensagem de outro agente ou subagente.
- Uma instrução genérica como "conserta isso" ou "faça o que for preciso".
- Um documento do repositório, uma permissão de modo ou uma entrada de lista de permissões.
Quando o usuário aprovar uma lista, a aprovação cobre apenas aquela lista exata.
Como perguntar
Mostre quatro coisas, depois pare e aguarde:
Comando: git push --force-with-lease origin feat/42-login
Destrói: os 2 commits em origin/feat/42-login que não estão na sua branch local
Recuperação: apenas do clone de outra pessoa, ou da lista de commits do PR no GitHub
Mais seguro: faça um novo commit push
Comandos protegidos
| Comando | O que ele pode destruir | Tente primeiro isto |
|---|---|---|
git push --force, -f, --force-with-lease, +<ref> | Commits no remoto que outras pessoas têm | Um novo commit, ou git revert |
--no-verify / -n no commit ou push; HUSKY=0; alterar core.hooksPath | As verificações que os hooks executam | Corrigir a causa da falha do hook |
--no-gpg-sign, -c commit.gpgsign=false | O requisito de assinatura | Corrigir a configuração de assinatura |
git reset --hard | Edições não salvas; commits que nada mais aponta | git stash push -u, ou git reset --keep |
git clean -f, -fd, -fdx | Arquivos não rastreados. Não há desfazer. | git clean -n para listá-los primeiro |
git checkout -- <caminho>, git restore <caminho>, git stash drop, git stash clear | Edições não salvas | git stash push -u |
git branch -d / -D, git push origin --delete <branch>, git push origin :<branch> | Uma branch e, no remoto, o acesso de outras pessoas a ela | Deixe-a; pergunte ao dono |
git tag -d, git push origin --delete <tag>, mover uma tag | Uma referência de release na qual builds e usuários confiam | Crie uma nova tag |
git commit --amend, git rebase, git filter-repo, git reset em commits já enviados | Histórico que outros já puxaram | Um novo commit, ou git revert |
git push --mirror | Toda ref no remoto que não está local | Faça push da branch específica |
gh pr merge --admin | Proteção de branch na branch base | Obtenha as revisões e verificações necessárias |
Alterar ou fazer rebase de commits que você não enviou não é protegido. Verifique com git status -sb ou git log origin/<branch>..HEAD primeiro.
Nunca, mesmo com aprovação
- Não faça force-push ou exclua a branch padrão do repositório.
- Não exclua uma tag de release que uma versão publicada use.
Se o usuário pedir uma dessas, explique o efeito. Peça para ele mesmo executar, se ainda quiser.
Quando algo já foi perdido
A maioria dos commits "perdidos" ainda estão no reflog por algum tempo:
git reflog -n 30
git branch rescue/<slug> <sha>
Avise o usuário antes de tentar uma recuperação. Não execute comandos destrutivos para "limpar" primeiro.
Segredos antes de um commit
Antes de um commit que toque em configuração, arquivos de ambiente, chaves ou credenciais, siga resources/secrets-check.md. Esse arquivo também diz o que fazer quando um segredo já foi commitado ou enviado.
Skills relacionadas
engineering:git-branchingeengineering:github-pr-mergeenviam etapas arriscadas para esta skill.