我喜欢的 Git 工作流

原则：小而频繁的提交

我见过太多人等到功能"做完"才 commit，结果是一个包含 47 个文件的巨型提交，commit message 写着"完成用户模块"。这种提交在 code review 时是灾难——没人能理解每一步为什么要改。

我自己遵循两个简单的原则：一，每个 commit 只做一件事；二，commit message 用祈使句写原因而不是描述做了什么。

具体做法

写新功能时，我习惯按这个节奏来：先写接口定义，commit；然后写核心逻辑，commit；加错误处理，commit；最后写测试，commit。每一步都是独立可 review 的。

修 bug 时更简单：先写一个能复现失败的测试，commit（标明这是失败的）；然后改代码让测试通过，commit（标明修复）。这样 reviewer 可以清楚地看到 bug 是怎么被修好的。

Rebase 还是 Merge

个人项目我用 rebase，保持线性历史干净好看。团队项目我偏好 merge，因为 rebase 会丢失"这个分支是什么时候开始的"这一上下文。没有哪个是绝对正确的，关键看团队的偏好和项目的规模。