git revert 是唯一安全的协作回退方式，因为它不改写历史，而是创建反向提交抵消变更，保留完整记录；而 git reset --hard + force-push 会破坏他人仓库一致性，引发冲突或提交丢失。
git revert 撤销已 push 的提交，为什么必须用它而不是 reset
已经推送到远程分支的提交，**不能直接用 git reset --hard 回退再 git push -f**。因为强制推送会改写历史，其他协作者执行 git pull 时会遇到非快进（non-fast-forward）拒绝，或更糟——他们本地分支被意外重置、丢失未同步的提交。
git revert 是唯一安全的协作场景选择：它不删除历史，而是生成一个新提交，内容恰好抵消目标提交的变更。所有人拉取后自动获得“回退效果”，且原有提交记录完整保留。
- 适用前提：提交已
git push到共享分支（如main、develop） - 不适用场景：你想彻底抹除某次提交（比如误提交了密钥），此时必须用
git filter-repo等工具，revert无效 - 注意：如果目标提交是合并提交（merge commit），需加
-m 1参数指定主干父提交，否则会报错fatal: Reverting a merge requires specifying which parent is the mainline
撤销非最近一次的提交，如何避免冲突和手动合并
执行 git revert <commit_hash> 撤销中间某次提交时，Git 会尝试应用“反向补丁”，但很可能失败并进入冲突状态——尤其当后续提交修改了同一文件的同一区域。
这不是 bug，而是设计使然：Git 不知道你是否希望保留后续提交的逻辑，所以把决定权交给你。
检查并更新通过 GitHub git clone 安装的 OpenClaw skills，适用于用户提到“更新skill”“检查 skill 是否有新版本”“GitHub 安装的 skill 是否有更新”“帮我检查本地 skills 是否落后”“更新 git clone 装的 skill”“拉取...
- 冲突出现时，会看到类似
Auto-merging src/index.js后跟CONFLICT (content): Merge conflict in src/index.js - 解决方式不是“删掉当前代码”，而是打开冲突文件，找到
<<<< HEAD和>>>> <revert-commit-hash>区块，**手动保留目标提交前的状态**（即 revert 所期望的“旧内容”） - 确认无误后运行
git add src/index.js && git revert --continue，不要用git commit - 若中途想放弃，用
git revert --abort，一切恢复原状
批量撤销多个提交，revert 的范围写法和陷阱
git revert 支持连续范围，但语法容易误解。关键点：范围是“从哪个提交开始撤销，到哪个提交结束”，且**右边界不包含**。
-
git revert HEAD~2..HEAD→ 撤销倒数第 2 次到倒数第 1 次（共 2 次），等价于git revert HEAD~1 HEAD -
git revert a1b2c3^..d4e5f6→ 撤销从a1b2c3的父提交之后，到d4e5f6为止的所有提交（不含a1b2c3^，含d4e5f6） - 错误写法：
git revert d4e5f6..a1b2c3（顺序颠倒）会导致“空范围”，命令静默退出，什么也不做 - 强烈建议先加
--no-edit参数避免编辑器阻塞，确认日志输出无误后再真正执行
revert 提交后推送到远程，为什么有时会失败
执行完 git revert 后，本地多了一个提交，但 git push origin main 仍可能失败，常见原因只有两个：
- 远程分支已有新提交：别人在你 revert 期间又 push 了。此时必须先
git pull，Git 会自动将 revert 提交与新提交线性合并（不会冲突），再git push - 远程分支受保护（如 GitHub/GitLab 的 branch protection）：禁止直接 push，即使你是管理员。需在 UI 中临时关闭
Require linear history或Include administrators选项，或走 PR/MR 流程 - 切记：不要因为 push 失败就转头去用
git reset --hard+push -f—— 这等于把问题从“同步失败”升级成“历史污染”
最易被忽略的是：revert 本身是一次普通提交，它会被 CI/CD 流水线触发构建和测试。如果被 revert 的原始提交引入了破坏性变更（比如删了关键配置），而 revert 提交又没通过测试，那整个修复流程就卡住了——得先定位为什么 revert 失败，而不是反复重试 push。
