前言
如果大家学习了之前的文章《Git新手教程-向仓库中添加commit(五)》，我相信大家肯定还会为如何提交一个比较规范的 commit 信息而烦恼，虽然我们在上面的文章中介绍了两篇相关的文章：
我相信大家肯定还是会疑惑，这里就以我之前理解的 commit 规范为列子。希望起到一个抛砖引玉的作用。毕竟 commit 信息只是人为规范，不同公司，不同项目，不同人有着自己的见解。因为作者本身是一名爱岗敬业的 Android 程序员，可能提交日志相对于倾向于移动端，所以如果大家有更好的提交日志分享。这里非常欢迎在评论中看到你的回答~
关于我的日志提交规范
整个信息结构由两个不同的部分构成，这些部分由空行分割：标题、可选的消息体。
标题
消息体
复制代码具体的结构如下所示：
类型:【项目组名称/简称】【Bug ID】【有无风险】【有无依赖】【需求/Bug描述】
- 分析:
- 风险:
- 解决方案:
- 测试建议:
- 适用范围:
- 测试机型:
- 自测结果:
复制代码标题
标题一般情况下，都不超过50个字符，末尾不加句号。如果50个字符还不能很清楚的描述你这次的 commit 。那么你可以在消息体中具体描述。接下来我们就分别介绍标题中涉及到的选项。
类型（必填）
类型位于在标题内，有以下几种可能：
- feat：新功能
- fix：错误修复
- docs：文档修改
- style：格式、分号缺失等，代码无变动
- refactor：生产代码重构
- test：测试添加、测试重构等，生产代码无变动
- chore：构建任务更新、程序包管理器配置等，生产代码无变动。
添加类型主要的目的，不仅是为了帮助自己或其他人理解对应 commit 主要干了什么，还可以筛选同类型的提交。比如我们可以筛选出所有的feat(新功能） ，那么在发布新版本的时候，我们能更好的书写版本发布日志。
项目组名称/简称（非必填）
填写项目组名称或者简称，但是一般建议简称。这样我们就能迅速找到该项目组提交的代码。代码如果出现了问题，我们也能快速定位到哪个组该背锅，你说是不？
Bug Id（必填）
Bug Id 需要对应你自己的公司项目的管理工具，如 JIRA、Icafe、Teambition 等，这里将 Bug Id 放在标题内，也是考虑到起到一个快速定位的作用，放在标题处显眼！！！
有无风险(非必填)
在实际的项目开发中，往往会涉及到系统版本兼容问题、数据库迁移问题、特定版本API使用问题、项目新老版本适配问题等其他风险。在项目开发中，我们需要将这些风险明确指出。 如果你这次提交内容中包含一些风险因数，那么这里我们就可以添加【有风险】，具体什么风险，我们可以在消息体中的风险模块中具体描述。
有无依赖(非必填)
这里有无依赖是指的是否依赖其他模块，如果公司的项目很大，一般都会涉及到多模块，不同模块之间肯定会有依赖关系。这里举一个简单的例子，假如我们开发的是一个商场项目，现在我们是基础业务组，现在有一个需求#331，需要让我们实现点击某个商品，完成购物，那么我们肯定会涉及到用户支付，而支付又是支付组在负责。那么在进行 commit 提交时，我们就可以添加【依赖支付模块】，这样做不仅可以让我们的测试工程师清晰的知道需求所包含的模块。也能在功能出现问题的时候，能够找准方向，对症下药。
需求/Bug描述（必填）
在标题处，通过对需求与Bug的简短的描述，也能快速的让其他人知道我们这个提交到底是做什么的。一般情况下，简短扼要的描述就行了，如果你觉得简短的语句并不能很好的概述所需要解决的问题，那么你可以在消息体中在进行详细的描述。
消息体（选填）
消息体，可以看做对标题的细致描述。并不是所有的提交信息都复杂到需要消息主体，因此这是选填内容，仅在提交信息需要一定的解释和语境时使用。消息体主要用于解释与完善提交任务的内容和原因。接下来我们就来分别讲解消息体中包含的其他选项。
分析（选填）
分析模块：主要对需求的场景分析与Bug出现的原因进行介绍。这里分析的作用非常重要。不仅能验证开发人员对功能或 Bug 的理解程度，还能减少公司新来的小伙伴阅读代码，了解业务的时间。
风险（选填）
风险模块：是对标题中的【有风险】进行详细的阐述。具体怎么描述，根据自己的实际项目而定。
解决方案 （选填）
解决方案模块：该模块主要针对于性能优化，Bug修复。主要用于解释所解决的问题的方式方法。
测试建议 （选填）
测试建议模块：该模块主要针对于新功能开发，Bug修复。在该模块中，我们可以详细说明，有哪些界面，哪些功能需要测试。这对于采用自动化打包工具（比如 Jenkins）的 团队特别有用，因为我们的测试小伙伴可以在使用自动化打包工具打包时，就能看见你提交的 commit ，那么根据你提供的测试建议，他们也能知道到测试过程中需要着重测试的地方以及需要注意的地方。
适用范围 （选填）
适用范围模块：该模块主要包含的内容 取决于 commit 的内容是针对某一系统版本，针对于特定设备，还是包含所有。这里可以根据自身的提交来填写。
测试机型(选填)
因为作者我是一名 Android 程序员，所以这里单独抽出了测试机型，也是合情合理的。
测试机型模块：该模块主要包含内容为你当前项目所运行的设备机型。当然因为 Android 的碎片化，在实际的项目开发中，我们可能会考虑不同厂商下的不同手机型号下的不同系统版本适配的问题。所以这里的机型，并不是唯一值，还是要根据自身的提交来填写。
（PS:Android 程序员就是这么辛苦，为什么工资没有 IOS 的高，不开心。）
自测结果
自测结果模块：完成新功能或修改 Bug 后，填写自测结果。不仅是对我们自己工作成果的验收，还能减少因为代码的问题而增加的返工次数，虽然我们不能保证自己测试后，就没有任何的问题了，但是至少我们的态度是端正的对吧~
其他注意事项
在进行 commit 时，我们仍然需要注意以下事项：
- 我们需要保证对项目的 commit 是针对新增某一个功能或修复某一个Bug 所作的提交。而不是该提交中包含对其他功能模块的修改。
- 我们尽量创建短小而明确的 commit ，什么是短小而明确的 commit 呢？其实很简单，我们的 commit 所涉及的文件最好不要超过10多个文件或数百行的代码更改。我们的 commit 要有针对性。
题外话
虽然了解一个项目的最好的方式就是 read the fucking source code，但是如果项目本身有着良好的 commit ，总会给我们带来事半功倍的效果对吧。从一些小事严格要求自己，我相信以后总会为我们带来一些特别的惊喜~~
