关于 organize-commits
这项开发技能可将分支历史整理为逻辑清晰的小提交，并要求每个提交都能构建且通过测试。它指导开发者安全地重组提交、撰写说明原因的提交信息、逐个验证，并在必要时经批准后强制推送。
主要功能
- 01按逻辑拆分变更
- 02按便于审查的顺序排列提交
- 03逐个提交验证构建与测试
- 04撰写说明变更原因的信息
- 05使用备份分支和安全推送方式
适用场景
- 01准备功能分支以供审查
- 02将混杂变更拆为独立提交
- 03整理历史以便使用 git bisect
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/organize-commits确认已加载。
详细介绍
整理提交
将一个分支上的工作重组为一系列提交，让审阅者可以一次审阅一个提交，并且每个提交都能独立构建并通过测试。
条理清晰的提交日志，是理解最能长久留存的地方之一：每条提交消息都承载着差异无法表达的“原因”，而提交顺序本身也能让审阅者了解这项更改的推理过程。这项技能旨在产出这样的成果。
原则
每个提交都必须满足以下所有条件：
- **一个逻辑更改。**不要将重构与行为更改混在一起。机械性更改（如格式调整、重命名）应单独提交。
- **在该历史节点上可构建并通过测试。**不留“下一个提交会修复”的技术债——这正是
git bisect有意义的原因。 - **消息解释原因。**差异已经展示了更改内容。记录约束、被否决的替代方案和隐藏的不变量。
- **顺序承载含义。**通常是：准备性清理/重构 → 基础设施/新增内容 → 新行为 → 调用点迁移 → 删除无用代码 → 测试/文档。后续提交绝不能部分撤销前面的提交。
- **保持小巧。**应能一次读完。如果感觉太大，几乎总是可以进一步拆分。
流程
1. 评估当前状态
并行运行：
git status
git log --oneline @{upstream}..HEAD # no upstream → use main/master
git diff --stat <base>...HEAD
git diff <base>...HEAD # skim the full diff once
<base> 通常是 origin/main 或 main。如果不确定，请询问用户。
2. 将更改分成逻辑单元
通读完整差异，并从“我会如何向审阅者解释这项更改”的角度进行分组。例如：
- 准备性重构（不改变行为）
- 新模块/类型/辅助函数（暂时没有调用方）
- 新行为
- 调用点迁移（旧 → 新）
- 删除无用代码
- 测试/文档
简要展示分组并征求同意。（超过 3 个提交时，几乎总是应该先展示分组。）
3. 建立安全网
重写任何内容之前，创建备份分支：
git branch backup/<current>-$(date +%s)
如果工作树中有未跟踪或未提交的更改，请先暂存或提交，并告知用户。
4. 选择重组方法
提出适合当前情况的方法：
- 单个提交，或仅涉及工作树：运行
git reset，然后逐个暂存差异块并重新提交git reset <base> # or reset --soft HEAD~N git add -p # pick hunks per group git commit -m "..." - 对多个提交重新排序/压缩：
git rebase -i <base>——**但-i是交互式的，无法在此环境中直接运行。**将命令交给用户运行，或使用git rebase --onto+ cherry-pick 以非交互方式处理。 - 更改可按文件清晰拆分：重复执行
git add <file>+ commit。 - 更改在同一文件内拆分：使用
git add -p（按s拆分差异块，按e进行逐行编辑）。
5. 验证每个提交
这是确保提交可逐个二分检验的关键。创建每个提交时：
<build command> # project-specific; at minimum type check / lint
<test command> # at minimum the fast unit tests
如果失败，修复该提交（git commit --amend 或使用 fixup + autosquash）。绝不能指望“下一个提交会修复它”。
完成整个序列后，再验证一次：
git rebase <base> --exec '<build>; <test>'
如果此步骤通过，则每个提交都单独通过验证。
6. 提交消息
主题行（约 50 个字符）+ 空行 + 正文（每行不超过 72 个字符）。正文应说明：
- 为什么需要此更改
- 考虑过并否决的替代方案（如有）
- 审阅者可能忽略的约束/不变量
- 此提交在整个系列中的位置（例如：“调用点将在后续提交中迁移”）
先检查仓库现有的风格（git log）——如果使用 Conventional Commits，请遵循该规范。
7. 推送
已推送的分支需要强制推送。务必先征得用户明确同意，并使用 --force-with-lease。绝不对 main/master 强制推送。
git push --force-with-lease -u origin <branch>
安全规则
- 没有备份分支，绝不重写历史。
rebase -i是交互式的——绝不要在此环境中直接调用；应引导用户操作，或使用非交互式替代方法。- 不使用
--no-verify，也不使用不带 lease 的git push -f，除非用户明确要求。 - 如果不知道构建/测试命令，请查阅
CLAUDE.md、package.json、Makefile、README；如果仍不清楚，请询问。 - 如果某个提交变得过大，请停下来与用户讨论进一步拆分。
反模式
- 在最终历史记录中留下“WIP”“fix”“address review”等毫无意义的消息
- 两次修改同一个文件，第二次提交又部分撤销第一次提交的更改
- 在同一个提交中混合重构和行为更改
- 在实现之前提交仅包含测试的更改*（该提交中的测试会失败 → 二分查找就会出问题）*
- 最后只运行一次
npm test，然后报告“测试通过”——每个提交都必须通过测试，否则二分查找就毫无意义