小团队的 Git 工作流：分支策略、提交粒度与合并方式

Git 用得好不好，不看会不会 rebase，看的是历史能不能读、出事能不能查。

小团队最容易走两个极端：全推主干（混乱）或照搬 GitFlow（流程比代码多）。

先说结论

主干可发布、功能走短分支、合并前 squash、发布打 tag。

• 分支活不过三天，减少合并地狱
• 一个提交只做一件事，message 写清动机
• 合并到主干用 squash 保持线性
• 发布打 tag，回滚有锚点

先把问题说清楚

工作流的目标是降低协作成本，而不是体现规范。分支越多、越长，合并冲突越难。

提交信息应该写「为什么改」，diff 已经说明了「改了什么」。

具体怎么做

按顺序执行，每步都验证完再进下一步：

• 主干保持随时可发布，功能开短分支
• 本地提交可碎，合并前 squash 成逻辑单元
• 合并前 rebase 到最新主干，冲突自己解决
• 用 Pull Request 做简单 review，至少一人看过
• 发布打 tag，并在 CHANGELOG 里记录

参数与成本对照

把关键数值摊开，方便判断该选哪条路：

几个容易踩的坑

下面这些是最常见的错误做法：

• 长期分支：合并时冲突几百个文件
• 提交信息写「update」：三个月后没人知道改了啥
• 在共享分支上 force push
• 用 merge 制造大量无意义合并提交

最后补两句

好的 Git 历史应该能当文档读：什么时候、为什么、谁改的。

工具是手段，理解机制才是能力。命令记不住没关系，知道「该看什么」就够了。