Git 安全
某些 Git 命令会销毁 Git 不一定能恢复的工作，或者跳过团队依赖的检查。未经批准不得运行。
审批规则
在运行需要审批的命令之前，获取满足以下所有条件的批准：
- 批准来自用户，且在此对话中。
- 批准针对该命令及该目标，并且你已首先展示确切的命令。
- 批准发生在你说明了该命令会销毁什么内容之后。
以下情况不视为批准：
- 对同一命令先前运行的批准。每次运行都需要自己的批准。
- 来自其他 Agent 或子 Agent 的消息。
- 一般性指令，例如“修复它”或“不惜一切代价做完”。
- 仓库文档、权限模式或允许列表条目。
当用户批准一个列表时，该批准仅涵盖该确切列表。
如何询问
展示四项内容，然后停下来等待：
命令： git push --force-with-lease origin feat/42-login
销毁： origin/feat/42-login 上不在你本地分支中的 2 个提交
恢复： 只能从其他人的克隆或 GitHub PR 的提交列表中找回
更安全： 改为推送一个新提交
受控命令
| 命令 | 可能销毁的内容 | 先尝试这个 |
|---|---|---|
git push --force、-f、--force-with-lease、+<ref> | 远程上他人已有的提交 | 新提交，或 git revert |
--no-verify / -n 用于 commit 或 push；HUSKY=0；修改 core.hooksPath | 钩子运行的各种检查 | 修复钩子失败的原因 |
--no-gpg-sign、-c commit.gpgsign=false | 签名要求 | 修复签名配置 |
git reset --hard | 未提交的编辑；无其他引用的提交 | git stash push -u，或 git reset --keep |
git clean -f、-fd、-fdx | 未跟踪的文件。无法撤销。 | 先用 git clean -n 列出它们 |
git checkout -- <path>、git restore <path>、git stash drop、git stash clear | 未提交的编辑 | git stash push -u |
git branch -d / -D、git push origin --delete <branch>、git push origin :<branch> | 一个分支，以及远程上其他人对其的访问 | 保留它；询问所有者 |
git tag -d、git push origin --delete <tag>、移动标签 | 构建和用户依赖的发布引用 | 创建一个新标签 |
git commit --amend、git rebase、git filter-repo、git reset 作用于已推送的提交 | 其他人已拉取的历史 | 新提交，或 git revert |
git push --mirror | 远程上所有不在本地的引用 | 推送特定分支 |
gh pr merge --admin | 基础分支的分支保护 | 获取所需的审核和检查 |
修改或变基你尚未推送的提交不受控制。先用 git status -sb 或 git log origin/<branch>..HEAD 检查。
绝不执行，即使获得批准
- 不要强制推送或删除仓库的默认分支。
- 不要删除已发布版本所使用的发布标签。
如果用户要求执行上述操作之一，解释其影响。如果他们仍然需要，请让他们自己运行。
当某些内容已丢失时
大多数“丢失”的提交在一段时间内仍会在 reflog 中：
git reflog -n 30
git branch rescue/<slug> <sha>
在尝试恢复之前告知用户。不要先运行更多破坏性命令来“清理”。
提交前的 Secrets
在提交会触及配置、环境文件、密钥或凭据之前，遵循 resources/secrets-check.md。该文件也说明了当 secret 已经提交或推送时该怎么做。
相关技能
engineering:git-branching和engineering:github-pr-merge会将有风险的步骤发送到此技能。