log提交规范详解 - 团队协作中如何写好Git提交信息

在开发项目时，你有没有遇到过这样的情况？翻看 Git 提交记录，满屏都是“fix bug”、“更新代码”、“临时提交”这种让人摸不着头脑的 log 信息。想查一个问题是什么时候改的，结果点开一看，啥也没看出来。这种情况不仅耽误自己时间，也给同事协作带来麻烦。

写代码不是一个人的事，尤其在多人协作的项目里，清晰的提交记录就像一本项目日记。它能告诉别人你做了什么、为什么做、影响了哪些部分。一个合格的提交信息，应该让人一眼看懂改动意图，而不是靠猜。

比如你把登录按钮从蓝色改成绿色，提交信息写成“修改颜色”就太模糊了。换成“feat(login): 将登录按钮改为绿色以提升点击率”，是不是清楚多了？前者让人困惑，后者直接说明了功能模块、改动内容和目的。

很多团队会采用类似 Conventional Commits 的规范，用固定的前缀来分类提交类型。下面这几个是最常用的：

这些前缀不是死规定，但统一使用能让日志更有条理。比如你看到一条“fix(api): 修复用户 token 过期未跳转登录页”的提交，马上就能知道问题出在哪，不用再翻代码去猜。

格式上一般推荐“类型(范围): 简要描述”，比如：

feat(user-profile): 添加用户头像上传功能

如果改动复杂，可以在后面加上详细说明，甚至关联 issue 编号：

fix(order-list): 修复订单状态显示错误

订单在“已发货”状态下误显为“待付款”
影响安卓端 v2.3.0 及以上版本
关联 issue #1248

注意第一行尽量控制在 50 个字符以内，这是很多工具默认展示的长度。换行后的补充内容可以自由发挥，讲清楚背景和解决方案就行。

刚开始写规范提交可能会觉得麻烦，但养成习惯后反而节省沟通成本。你可以把常用模板记在编辑器片段里，或者让团队在 Git 提交前走一遍 checklist。

另外，别忘了提交前先 pull 最新代码。曾经有同事连续三条提交都是“merge branch”，完全淹没了真正的改动内容。这种低级错误虽然好笑，但在紧急上线时真有人干过。

有些公司还会配合工具自动生成 changelog，这时候规范的提交信息就派上大用场了。系统能自动识别 feat 和 fix，生成版本更新说明，省得人工整理。

让团队协作更顺畅：聊聊log提交规范的那些事儿