git commit 格式限定标准

​ 在日常git使用中，没有注意过git commit规范，每次进行提交都是随意进行说明。现在起开始规范自己的git commit 规范，参考各种开发规范，确定以下commit规范。

简介：

​ commit message应该如何写才更清晰明了？团队开发中有没有遇到过让人头疼的git commit？本文说明了自己在git commit规范建设上的实践，规定了commit message的格式。

规范确定

​ 先前自己通过浏览开发文档都明确了自己的commit message 开发规范，我鉴于参考文档，得到下面的规则准则。

commit 格式

<type> (<scope>) : <subject>

注意： >与( ，) 与 : ，: 与 < 必须用一个空格分隔

• type 必选 -> (用于说明git commit的类别，只允许使用下面的标识)
  • feat：新功能（feature）
  • fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG
    • fix：产生diff并自动修复此问题。适合于一次提交直接修复问题
    • to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix
  • docs：文档（documentation）
  • style：格式（不影响代码运行的变动）
  • refactor：重构（即不是新增功能，也不是修改bug的代码变动）
  • perf：优化相关，比如提升性能、体验
  • test：增加测试
  • chore：构建过程或辅助工具的变动
  • revert：回滚到上一个版本
  • merge：代码合并
  • sync：同步主线或分支的Bug。
• scope 可选 -> （用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同）
• subject 必选
  • 说明:
    • 1. subject是commit目的的简短描述，不超过50个字符 (ZH/CN)
    • 2. 建议使用中文（感觉中国人用中文描述问题能更清楚一些）

格式用例

fix (DAO) : 查询所有用户
test (main) : add chainTree test code

规范要求

上面就是参考文档确定的自己git commit规范，这样规范git commit到底有哪些好处呢？

• 便于自己或者团队对提交历史进行追溯，了解发生了什么情况
• 一旦规定了commit message，那提交时会慎重的进行，不能再把各种修改都放在一个git commit里面，这样一来整个代码改动的历史也将更加清晰
• 格式化的commit message才可以用于自动化输出Change log