git-commit-rewrite

Git 提交重写

概述

将近期历史记录中不符合规范的提交主题重写为 Conventional Commits 格式。具有破坏性——会更改提交 SHA。不会悄悄重写已推送的提交；而是显示一个包含 3 个选项的菜单（取消 / 强制推送 / 基于分支）。

**强制模式：**如果调用中包含 force 或 --force 令牌，则跳过该菜单和其他所有交互确认关卡，并强制推送重写结果——请参阅主 git-commit/SKILL.md 中的“强制模式”。

开始时声明：“我正在使用 git-commit-rewrite 技能重写这些提交消息。”

工作流

开始之前，请阅读主 git-commit SKILL.md，路径为 <plugin-root>/skills/git-commit/SKILL.md——安全检查详情、正则表达式、“常见不符合规范模式映射”表、原地 / 基于分支的重写脚本以及重写后的清理命令都在其中。本变体依赖这些内容。

然后严格遵循主 SKILL.md 中的 ## Workflow: /git-commit-rewrite。步骤：

1. 确定重写范围——默认基点为上游合并基点（或 main / master 的合并基点）；如果用户指定数量，则使用 HEAD~N。绝不使用 --root。
2. 运行安全检查 A、B、C——工作区干净；HEAD 已关联分支；检查范围内是否有任何提交位于远程。
3. 如果提交已推送，显示包含 3 个选项的菜单（取消 / 强制推送 / 基于分支）。不要悄悄拒绝。默认选择取消。
4. 使用 Conventional Commits 正则表达式识别不符合规范的提交；使用 --no-merges 跳过合并提交。
5. 使用“常见不符合规范模式映射”表生成新消息；将工单前缀（例如 proj #N:）移至 Refs: 页脚；逐字保留每条原始正文。
6. 展示旧消息 → 新消息的计划并等待明确确认。
7. 应用重写：
   • 选项 2（原地）：使用 git filter-branch --msg-filter、scripts/rewrite_msg.py 和 /tmp/cc-rewrite-map.tsv 中的映射，然后运行 git push --force-with-lease（绝不使用 --force）。
   • 选项 3（基于分支）：从基点创建 ${branch}-cc，逐个 cherry-pick 提交，并使用新消息执行 --amend，然后推送新分支。
8. 重写后：显示 git log --oneline <base>..HEAD；告知用户如何删除 refs/original/ 备份；清理 /tmp/cc-rewrite-map.tsv。

强制模式（force 关键词）：如果调用中包含独立令牌 force 或 --force（不区分大小写），则表示用户已预先同意——跳过步骤 2 的安全检查，跳过步骤 3 的菜单（即使提交已推送，也自动执行原地重写），并在步骤 6 展示计划但不等待。应用更改后，如果任何被重写的提交已位于远程，则最后执行 git push --force（不带其他参数——唯一允许使用它的情况）。Git 自身对 filter-branch 的限制仍然适用。完整规则：主 git-commit/SKILL.md 中的 ## Workflow: /git-commit-rewrite → “强制模式”。

脚本位于 <plugin-root>/skills/git-commit/scripts/rewrite_msg.py（在主技能中——各变体共用该脚本）。

危险信号

与主 <plugin-root>/skills/git-commit/SKILL.md> 中的 Never / Always 列表相同。特别注意：

• 绝不使用 --force 推送——强制模式（force 关键词）除外，此时裸 --force 是用户主动选择的方式；其他情况只能在用户明确同意后使用 --force-with-lease。
• 绝不在未先显示包含 3 个选项的菜单时重写已推送的提交——强制模式除外，此时该关键词代表用户已预先同意。
• 绝不使用 git filter-branch --root。
• 绝不丢弃工单引用——将其移至 Refs: 页脚。
• 绝不重写合并提交——使用 --no-merges。
• 始终逐字保留原始提交正文。

集成

配合使用：git-commit——先提交工作区更改，再单独重写过时的历史记录。 **调用方式：**仅由用户手动调用。绝不在其他技能的工作流中自动运行。