Git Commit Message的最佳实践

Git Commit Message的最佳实践

在Git协作模式的团队中，Commit Message的规范版本控制起着很重要的作用。

Commit Message规范

• 在git开发流程中，每次git commit ，都需要对此次commit添加描述信息，描述此次commit的具体改动内容。规范的commit message格式，可以让团队成员对每次改动内容进行快速了解，也可以方便git log时的浏览和筛选。

• 阮一峰博客介绍commit message http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html

• 简述

  一条完整的提交信息 (commit message) 一般来说包含 Header 和 Body，其中 Header 是必须的，Body 是可选的。

  对于大部分可以简单描述清楚的改动，只需要一个 Header 即可。

  而对于一些需要更详细说明、要分条列出的改动，我们在 Header 进行简述之外，还要在 Body 中详细描述。

  一般而言，Header 长度不应超过 50 个字符，如果超过的话则考虑添加 Body 进行详述。

  我们通常使用的 git commit -m ""，就是只添加单行的 Header 信息。例如：

  	# 这里只添加了Header"
  	git commit -m "feat(官网主页): 将iOS的头部背景与Android统一，不再使用默认蓝色图片"

  如果需要添加 Body 详细信息，则使用 git commit 进入文本编辑器，再进行具体编辑。例如：

  	# 这里既添加了Header，又添加了Bodychore(构建优化): 解决构建流程几个问题
  	- 每次构建chunkhash会改变的问题- 内联和外链样式重复问题- 图片md5错误问题- 提取项目公共vendor

• 具体规范

  从上面的示例可以看到，Header 的格式为：():。

  Header 主要由 type, scope 和 subject 三部分组成：

  • type 用来描述这次提交属于哪一类修改，比如是完成需求还是修复BUG。（必需）
  • scope 用来描述这次提交涉及的范围，比如是详情页还是礼包页。对于一些没有明确范围的改动，可以忽略。（可选）
  • subject 是这次提交的简单描述，具体做了什么。如果 50 字符内不能描述清楚，建议添加 Body 继续描述。（必需）

  type 类别

  常用：

  • feat - 新增需求、需求迭代、新功能等相关的提交
  • fix - BUG 修复提交
  • docs - 文档相关的提交
  • refactor - 技术优化类的代码重构，不影响具体需求和逻辑，也不涉及 BUG 修复的修改，如：测速优化、性能优化、模块拆分等
  • chore - 代码维护相关的小改动，如：更新依赖库、构建工具及其配置的改动、代码格式调整等

  较不常用：

  • workflow - 开发工作流的改动，比如修改 package.json 中的 scripts，比如增加或修改一些发布脚本
  • test - 测试相关的修改，比如增加测试用例。

• Revert

  在需要回滚某些改动的时候，使用 revert: 格式，也就是将回滚的那一条提交的 Header 作为 revert 后的内容。

• 注意事项

  • scope 不是必须的，也没有具体的限定，但是有明显范围特征的尽量写上。
  • 注意描述要清晰，要针对改动本身，让其他成员在没有任何上下文的情况下，也能看懂改动了什么。
  • 不写废话；
  • typo 修正、代码格式调整之类的，在 AngularJS 标准里另分到 style 类别，我们统一放在 chore 当中。这些很细小的改动，描述可以不用特别详细；
  • 应保证改动和 commit 一一对应；
  • 一个 commit 只对应一处改动、一个需求或一个 BUG，不要把多个改动集中混在一起提交。在同时修改了多个文件时，不要直接 git add .，应该挑选相关的文件进行 add 和 commit，再挑选另一部分文件进行 add 和 commit；
  • 一处改动、一个需求或一个 BUG，应尽量集中在同一个 commit 中，不要开发到中途先提交一次，开发完成再提交一次。