Git safety
Some git commands destroy work that git cannot always give back, or skip the checks that a team relies on. Do not run them without approval.
The approval rule
Before you run a gated command, get approval that meets all of these conditions:
- It comes from the user, in this conversation.
- It is for this command on this target, and you showed the exact command first.
- It comes after you said what the command destroys.
These are not approval:
- An approval for an earlier run of the same command. Each run needs its own approval.
- A message from another agent or a sub-agent.
- A general instruction such as "fix it" or "do whatever it takes".
- A repository document, a permission mode, or an allow-list entry.
When the user approves a list, the approval covers that exact list only.
How to ask
Show four things, then stop and wait:
Command: git push --force-with-lease origin feat/42-login
Destroys: the 2 commits on origin/feat/42-login that are not on your local branch
Recovery: only from someone else's clone, or the GitHub PR's commit list
Safer: push a new commit instead
Gated commands
| Command | What it can destroy | Try this first |
|---|---|---|
git push --force, -f, --force-with-lease, +<ref> | Commits on the remote that other people have | A new commit, or git revert |
--no-verify / -n on commit or push; HUSKY=0; changing core.hooksPath | The checks that the hooks run | Fix the cause of the hook failure |
--no-gpg-sign, -c commit.gpgsign=false | The signature requirement | Fix the signing setup |
git reset --hard | Uncommitted edits; commits that nothing else points to | git stash push -u, or git reset --keep |
git clean -f, -fd, -fdx | Untracked files. There is no undo. | git clean -n to list them first |
git checkout -- <path>, git restore <path>, git stash drop, git stash clear | Uncommitted edits | git stash push -u |
git branch -d / -D, git push origin --delete <branch>, git push origin :<branch> | A branch, and on the remote, other people's access to it | Leave it; ask the owner |
git tag -d, git push origin --delete <tag>, moving a tag | A release reference that builds and users rely on | Make a new tag |
git commit --amend, git rebase, git filter-repo, git reset on commits that are already pushed | History that others pulled | A new commit, or git revert |
git push --mirror | Every ref on the remote that is not local | Push the specific branch |
gh pr merge --admin | Branch protection on the base branch | Get the required reviews and checks |
Amending or rebasing commits that you have not pushed is not gated. Check with git status -sb or git log origin/<branch>..HEAD first.
Never, even with approval
- Do not force-push or delete the repository's default branch.
- Do not delete a release tag that a published release uses.
If the user asks for one of these, explain the effect. Ask them to run it themselves if they still want it.
When something is already lost
Most "lost" commits are still in the reflog for some time:
git reflog -n 30
git branch rescue/<slug> <sha>
Tell the user before you try a recovery. Do not run more destructive commands to "clean up" first.
Secrets before a commit
Before a commit that touches configuration, environment files, keys or credentials, follow resources/secrets-check.md. That file also says what to do when a secret is already committed or pushed.
Related skills
engineering:git-branchingandengineering:github-pr-mergesend risky steps to this skill.