前言
制定一个 git commit 信息的提交规范是开发团队工作流必不可少的环节。试想一下，如果查看主分支上的历史库也就是你查看 git log 的时候，打印出来的信息杂乱无章的话，如果代码遇到问题，可能需要很大的精力与成本来查找到导致问题的代码提交，所以团队需要制定规范来引导成员编写规范的 commit 信息。
接下来的 commit 信息规范参考了 angularjs 团队的开发者指引与笔者的工作团队进行总结，读者如有需要可以以此为基础增加或修改成为自己团队的 commit 规范的一部分。
提交信息基本模板
如果 commit 信息都按照一定的模式进行提交，那么我们就会很容易找到自己想要的信息，模板参考如下：
<type>(<scope>): <subject> [<ISSUE_ID>]
<body>
<footer>commit 信息包括三个字段: type (必需)， scope(可选) 和 subject(必需)。
1、type。type 是用于说明该 commit 的类型的，一般我们会规定 type 的类型如下：
- feat: 新功能(feature)
- fix: 修复 bug
- docs: 文档(documents)
- style: 代码格式(不影响代码运行的格式变动，注意不是指 CSS 的修改)
- refactor: 重构(既不是新增功能，也不是修改 bug 的代码变动)
- test: 提交测试代码(单元测试，集成测试等)
- chore: 构建或辅助工具的变动
- misc: 一些未归类或不知道将它归类到什么方面的提交
2、scope。scope 说明 commit 影响的范围，比如数据层，控制层，视图层等等，这个需要视具体场景与项目的不同而灵活变动
3、subject。subject 是对于该 commit 目的的简短描述
- 使用第一人称现在时的动词开头，比如 modify 而不是 modified 或 modifies
- 首字母小写，并且结尾不加句号
4、ISSUEE_ID。这个与公司的需求管理与项目管理有关，假设你的项目放在 github 上，你的需求或者 bug 修复可能会有对应的 issues 记录，你可以加到你的 commit 信息中如 issue-37938634。
5、body 其实就是 subject 的详细说明，而 footer 中你可以填写相关的需求管理 issues id。
在企业中一般会对团队中要做的事情与需求开发使用一个软件进行管理，好处是可以让代码与对应的用户故事(story)或者需求，bug 进行关联，便于管理，类似的方案有 github，gitlab，tracker，JIRA 等等，比如在网易某些团队中就会使用 JIRA 加上 gitlab 来进行团队管理。
commit message 的规范性是很重要的，对于自己养成良好的编程习惯很有帮助，但是没有必要强制完全遵循开源团队的规范，毕竟每个团队与个人的情况不同，博采众长即可，当然你也可以使用像 commitlint 这样的校验工具从工具层面上来强制执行某些规范，这里就不展开讲了，有兴趣的读者可以查阅相关资料并使用到自己团队的实践中。
总结
本章节介绍了 git 的一些常用命令的操作与基本概念，与基于此的 git 合作流程与 commit 规范。对于 git 的使用，笔者建议多加练习，不能只"纸上谈兵", 实际操作才能加深对于 git 的理解，而 git 合作流程与 commit 规范提供了参考，大家结合上面章节的建议与实际团队的情况，相信会有更适合每个团队不同情况的实践。
个人见解
目前我们很多的团队在开发的过程中不一定不一定会按照这个规范来提交版本，但是既大牛们制定了这个规范，并且已经在市场上有很多人用，那就一定有他的好处，古话说的好“存在即必然”，也可以为以后的团队量身定制一套提交规范。
原文地址：https://www.yuque.com/fe9/basic/nruxq8
总结文章：https://www.jianshu.com/p/201bd81e7dc9?utm_source=oschina-app
613
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
