Git提交信息与分支策略：团队协作的隐形契约
很多开发团队有这样的经历：git log 一拉出来，满屏的”fix bug””update””111″”改好了”。提交信息是写给谁看的？不是写给 Git 看的，而是写给三个月后排查问题的自己、接手代码的新同事、以及需要判断”这个版本能不能发”的团队看的。它是团队协作里一份从不删除的文档，却常常被当成最不值得花时间的东西。约定式提交规范和合理的分支策略，就是给这份文档立的规矩——它本质上是团队之间的隐形契约。
一、为什么提交规范值得较真
第一，可追溯。线上出问题时，git bisect 能二分定位到引入问题的那个提交，但如果提交信息只写着”fix”，你依然不知道它改了什么、为什么这么改。第二，可自动化。规范的提交信息可以直接驱动工具生成变更日志，甚至按语义化版本自动决定发 minor 还是 major 版本。第三，可审查。提交小而清晰，Code Review 才看得进去；一次几百行的巨型提交，审的人只能点个”通过”。第四，可传承。新人读提交历史，就是在读这个项目的演进脉络，比任何文档都真实。
二、约定式提交：一套被广泛验证的格式
目前业界最通用的规范是约定式提交（Conventional Commits），Angular 团队是早期实践者。核心格式只有一行：类型(范围): 描述。类型必须是固定的几个词之一：feat表示新功能，fix表示修bug，docs表示文档，style表示格式调整，refactor表示重构，perf表示性能优化，test表示测试，chore表示杂务，ci表示持续集成相关。范围是可选的影响模块，比如feat(cart)。描述用祈使句、简洁明确，比如”feat(cart): 支持优惠券叠加使用”。如果提交包含破坏性变更，在类型后加感叹号，如”feat(api)!: 删除v1接口”，并在正文里用BREAKING CHANGE说明。
容易被忽视的是正文。约定是：描述区写”为什么”，不写”改了什么”——改了什么看 diff 就知道，为什么这么改才是 diff 里没有的信息。比如正文写”优惠券叠加导致新客立减失效，补上叠加条件的判断，防止活动期间出现双重优惠”。还可以在脚注里关联需求单号或 issue，让提交与任务系统打通。规范落地不能靠自觉，要用工具强制：commitlint 加 husky 钩子在提交时自动校验格式，不合规直接拒绝提交；commitizen 提供交互式填写向导，降低书写成本。
三、分支策略：按发布节奏选，别照搬
分支策略没有银弹，主流有三种：GitHub Flow 适合持续部署的团队——主干长期可发布，所有改动走短命的特性分支，通过拉取请求合入；Git Flow 适合定期发版的团队——master 存正式版本，develop 存开发集成，feature、release、hotfix 分支各司其职，规则完整但偏重。无论选哪种，有几条原则是通用的：主干要长期处于可发布状态；特性分支要短命，最好几天内合入，否则合并地狱会准时降临；拉分支前先同步最新主干；合入前把本地提交 rebase 到最新，保持历史线性可读——但已经推送到共享远端的分支不要随意 rebase，强行改写历史会让协作者崩溃。
四、一个案例：失控的提交历史如何拖垮排查
一家创业公司的电商后端，赶版本期间提交信息全是”fix””update””改好了”。三个月后一次灰度上线后订单数据异常，团队用 git bisect 定位到某个提交，但提交信息完全看不出改了什么，打开 diff 发现里面混着支付逻辑、日志代码和一次无关注释的修改——没人记得当时为什么动这里，只能靠猜。回滚时更棘手：不知道该把哪些后续提交一起回滚，最后选择整体回退三天，连带丢掉了一个本可以保留的功能。整顿之后，团队约定：每次改动一个原子问题、提交信息必须写清原因、PR 必须关联需求单。下一次线上问题出现时，从用户反馈到定位提交、确认影响范围，只花了十分钟。同样的排查工作，差的不是能力，是历史里有没有留下线索。
五、常见误区
- 巨型提交：一次提交塞进大量无关改动，无法审查、无法单独回滚。保持原子性——一次提交只解决一个问题。
- 正文写流水账：”修改了A文件、B文件”没有信息量。diff 已经告诉你怎么改，正文要回答为什么。
- 规范靠自觉：没有 commitlint 之类的强制校验，规范两周就会名存实亡。
- 分支长期不合并：特性分支活过两周，冲突成本指数上升，最后只能推倒重来。
- 随意改写已推送历史：force push 覆盖共享分支，队友的本地历史会直接错乱。rebase 只用于尚未推送的本地提交。
六、行动建议
本周就可以落地四件事：和团队敲定一份类型清单，接上 commitlint 强制校验；从下一个提交开始，标题一行说清改动、正文写清动机；把大改动拆成若干原子提交；给拉取请求模板加上”关联需求单”一栏。别小看这些小事——半年后当你靠 git log 三分钟定位一个历史问题时，你会感谢今天较真的自己。