git commit规范

前言

git作为一个代码管理工具，现在几乎成为一个程序员的必备技能了。其中的git commit message尤其重要，经常看到commit信息内有fix bug, change XXX等各种千奇百怪的描述，会气的一口老血上来。

commit message能够帮助我们定位一个提交主要是完成了什么功能，如何实现等。它应该清晰明了，因此特别写这一篇文章记录下相关规范(曾经的我也爱fix bug...)

规范

commit message格式:

1

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

接下来会一一讲解

type

type为必须填写。代表git commit的类别，且需要在以下类型中选择:

• feat: 新功能(feature)

• fix/to: 修复bug，fix代表产生diff并修复，适用于一次提交修复问题。to代表产生diff却没有修复，适用于多次提交修复问题，最终提交使用fix

• docs: 文档相关提交

• style: 格式，不影响代码功能的变动

• refactor：重构（即不是新增功能，也不是修改 bug 的代码变动）

• perf：优化相关，比如提升性能、体验

• test：增加测试

• chore：构建过程或辅助工具的变动

• revert：回滚到上一个版本

• merge：代码合并

• sync：同步主线或分支的 Bug

scope (可选)

scope 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同

例如，在后端服务中改动了某一个接口，那么scope就可以填写api

如果你修改了不止一个scope，可以用*来表示

subject

subject是commit目的的简短描述，不超过50个字符

这里没必要硬使用英文，是中文能够表达清楚也是可以的。举个例子：

1

git commit -am "feat(api): 用户登录接口的开发"

以上就是我们梳理的git commit规范，那么我们这样规范git commit到底有哪些好处呢？

• 便于程序员对提交历史进行追溯，了解发生了什么情况。

• 一旦约束了commit message，意味着我们将慎重的进行每一次提交，不能再一股脑的把各种各样的改动都放在一个git commit里面，这样一来整个代码改动的历史也将更加清晰。

总结

编码规范、流程规范在软件开发过程中是至关重要的，它可以使我们在开发过程中少走很多弯路。Git commit 规范也是如此，确实也是很有必要的，几乎不花费额外精力和时间，但在之后查找问题的效率却很高。作为一名程序员，我们更应注重代码和流程的规范性，永远不要在质量上将就。