Best Practices
原子提交专题
把一次提交收敛成单一逻辑变更，降低 review 和回滚成本。
- 希望把 Git 用得更稳的个人或团队
- 准备建立协作规范的维护者
- 至少有一次真实协作经验
- 知道常见命令但还没形成稳定习惯
- 把建议当硬规则而忽略上下文
- 只记流程，不理解背后的协作边界
为什么"原子提交"不是形式主义
修复 bug 的代码重构的代码格式化修改调试日志
commit 1: fix(auth): 修复登录超时commit 2: refactor(auth): 简化认证逻辑commit 3: chore: 格式化代码
使用 git add -p 可以按代码块选择暂存内容，将不同逻辑拆分到不同提交。
原子提交的核心不是让历史看起来整齐，而是让每一条提交都能独立解释、独立 review、独立回滚。只要一次提交里混进多个意图，后面的所有动作都会变重：
- reviewer 很难快速判断边界
- revert 往往会误伤不该撤回的改动
- cherry-pick 更容易带进无关上下文
- 事故排查时很难看懂“到底哪次改动引入了问题”
所以原子提交不是“高级习惯”，而是把协作成本压低的基础动作。
1. 一个提交只表达一个逻辑意图
最实用的判断标准不是“改了几个文件”，而是“这些改动是不是在回答同一个问题”。
下面这些通常适合成为一个提交：
- 修复登录页空邮箱校验
- 重命名一组字段，让命名统一
- 补一组和某个接口变更直接相关的测试
下面这些通常不适合揉在一起：
- 修 bug 时顺手做样式微调
- 一次提交里同时改重构和行为逻辑
- 把格式化、命名修正、功能修复混成一条历史
2. 一个很好用的自检问题
提交前先问自己：
- 我能不能用一句话讲清这次提交在做什么？
- 如果现在只回滚这一条，会不会相对安全？
- 如果 reviewer 只看这一次提交，能不能理解我的意图？
如果这三个问题里有两个回答不上来，通常说明这次提交还不够原子。
3. 善用分块暂存，而不是先全加再祈祷
原子提交最实用的工具不是复杂脚本，而是：
git add --patch
它的价值在于把“提交边界”提前到暂存阶段，而不是等提交生成后再后悔。
当一个文件里同时混入重构和行为修复时，--patch 往往是最稳的拆分方式。
4. 原子提交对 review、revert、cherry-pick 都有直接收益
Review
reviewer 不需要先做“切分工作”，可以直接讨论改动本身。
Revert
当一次提交只表达一个意图时，回滚就更接近外科手术，而不是整片回退。
Cherry-pick
如果一个修复需要回移到旧分支，小而清晰的提交更容易准确搬运，不会把别的东西一起带过去。
5. 一个适合团队长期执行的最低标准
如果团队暂时还没有完整规范，先守住这四条就已经很值：
- 一个提交只做一件事
- 避免把重构和行为改动放在同一提交里
- 提交前先看
git diff --staged - 不确定时优先拆小，而不是继续往同一提交里塞
最后这一步尤其重要：
git diff --staged
它会让你在真正写出 commit 之前，再看一眼这次到底准备提交什么。