# Atomic Commit

> 将具有业务意义的完整提交单元整理为可直接回滚的本地提交。当用户要求提交或原子提交时使用。

- Skill: `zuozh11/atomic-commit` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add zuozh11/atomic-commit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zuozh11/atomic-commit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zuozh11 (https://skillmd.com/u/zuozh11)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zuozh11/atomic-commit

---


# Atomic Commit

核心目标是让每笔提交都具有可独立说明的业务意义，并能整笔直接回滚。提交边界由完整业务结果、交付完整性和回滚边界共同决定，不追求最小、最细。

## 原子性标准

- **业务意义**：完成该 commit 后，用户、角色或系统获得一项完整能力，或者产生一个可观察的业务结果。提交应能用业务语言说明价值，而不是只描述修改了哪些文件或技术层。
- **完整提交单元**：共同完成同一业务结果所需的实现、测试、文档、配置、迁移和生成文件放在同一 commit。该 commit 在其依赖基线之上能够完整成立、整体验证，不依赖剩余未提交改动。
- **可直接回滚**：可以通过整笔回滚该 commit 撤销这次交付，无需挑选 hunk、同时回滚无关提交或手工拼接恢复状态；回滚后不会留下明显残缺状态。
- **拆分边界**：只有形成不同且各自完整、能分别验证和回滚的业务结果时才拆分；不按文件数、技术层或提交类型拆分。

## 流程

按项目知识协议使用相关 CONTEXT 与适用 RULE；已有知识足够时复用，知识不可用时说明缺口并继续。

1. 优先根据当前会话理解变更目的和范围。查看 `git status`，并只读取划分提交边界和生成消息所需的相关 diff；不得为重新理解已知改动而扩大调查。
2. 在暂存前用业务语言说明每个提交单元完成后的能力或可观察结果，再验证其交付完整性和直接回滚能力。调用方已经给出边界时仍需完成该校验；不得根据文件分布或技术层次重新拆分完整业务结果。
3. 逐个提交单元执行：
   - 只暂存该单元的路径或 hunk；
   - 检查 staged diff，确认内容完整、没有无关改动，也不依赖剩余未提交改动；
   - 沿用当前会话已经完成的验证并如实保留验证边界；
   - 为 staged diff 生成消息并完成本地提交，再处理下一个单元。
4. 调用方给出的提交单元与 diff 不一致时，写入前返回边界冲突。改动归属不清，或用户要求的提交方式会破坏交付完整性或直接回滚能力时，提问确认。
5. 提交消息涉及业务术语时，使用 CONTEXT 中的统一术语，并使用以下格式：

   ```text
   <type>[(scope)]: <summary>

   [body]

   [footer]
   ```

6. 类型沿用项目约定；`scope` 优先使用稳定的业务领域，其次使用模块或组件，无法准确归类时省略。
7. `summary` 使用祈使语气，直接描述业务结果或工程交付价值，不写成文件操作清单。不加句号，标题不超过 72 个字符，沿用已确定的术语。
8. 仅在标题不足以说明内容或原因时添加 `body`；破坏性变更使用 `!` 和 `BREAKING CHANGE: <影响>`，关联信息按需写入 footer。

## 执行边界

- 只暂存当前会话相关的改动。如果已暂存内容的归属不清，在写入前提问确认。
- 不得自动 push。

## 示例

```text
fix(订单): 处理空订单号时不再崩溃
```