git revert是安全回滚已推送commit的唯一推荐方式，它通过创建新提交来逆向应用指定commit的修改，保留完整历史，适用于tag已推送、团队协作等场景。
不能直接“撤销 tag 对应的提交”——tag 本身只是指向某个 commit 的指针，删掉 tag 不会影响 commit，也不会回退代码。真正要做的，是回退 commit 本身，再按需处理 tag。
git revert 是安全回滚已推送 commit 的唯一推荐方式
当你打完 v1.2.0 标签、又把对应 commit 推送到远程，其他人可能已经基于它开发或部署。此时用 git reset 强制改写历史会破坏协作。
git revert 会生成一个新 commit，内容是原 commit 的逆操作，保留完整历史线：
git revert abc123
如果该 commit 修改了多个文件，revert 会尝试全部反向应用；若冲突，需手动解决并 git add + git revert --continue。
- 适用于：tag 已推送到远程、团队协作环境、CI/CD 已触发构建
- 副作用：历史中多出一个“撤销”commit，但可追溯、可审计
- 注意：
git revert默认只撤销单个 commit；若 tag 指向的是合并提交（merge commit），需加-m 1指定主干父节点
git reset --hard 只适用于本地未推送场景
如果 v1.2.0 标签和对应 commit 都没 git push 过，且你确定没人基于它工作，可以用 git reset 回退到前一个 commit：
git reset --hard HEAD~1
之后记得删掉本地和远程的 tag：
OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：
- 删本地 tag：
git tag -d v1.2.0 - 删远程 tag：
git push origin :refs/tags/v1.2.0（注意冒号前有空格）
⚠️ 错误示范：git push --delete origin v1.2.0 在部分旧版 Git 中不生效，:refs/tags/xxx 才是通用写法。
删 tag 不等于删 commit，别混淆这两件事
很多人以为删了 v1.2.0 就“撤回了发布”，其实 commit abc123 依然躺在本地仓库里，git log 能查到，git fsck 也能找回（7天内默认不被 GC）。tag 只是给人看的别名。
- 查看所有 tag：
git tag - 查看某 tag 指向的 commit：
git show v1.2.0 - 确认 commit 是否已被其他分支引用：
git branch --contains abc123
如果你删了 tag，但忘了同步删远程 tag，下次别人 git fetch --tags 还会拉下来——必须显式推送删除指令。
打错 tag 怎么补救？重打 + 强制推送
比如你本想打 v1.2.0，却误打成 v1.2.o，且已推送到远程：
- 删错 tag：
git tag -d v1.2.o+git push origin :refs/tags/v1.2.o - 重新打正确 tag：
git tag -a v1.2.0 -m "fix: correct version tag" - 强制推送到远程（仅当远程允许 force push）：
git push --force origin v1.2.0
⚠️ 注意：--force 对 tag 有效，但对分支默认禁止，除非显式配置 receive.denyNonFastForwards=false。很多企业 Git 服务（如 GitLab、Gitee）默认禁用 force push tag，需管理员开启。
最易被忽略的一点：tag 是轻量级还是附注型，决定了它能否携带签名和描述。用 git tag v1.2.0 打的是轻量 tag，无法用 git show 看消息；务必用 -a 或 -s 创建附注 tag，否则后续审计时连谁、何时、为何打标都查不到。
