Git新手教程-日志提交规范（五）补充

前言

若是你们学习了以前的文章Git新手教程-向仓库中添加commit(五)，我相信你们确定还会为如何提交一个比较规范的 commit 信息而烦恼，虽然咱们在上面的文章中介绍了两篇相关的文章：

• 怎么写 Git Commit Message
• Commit message 和 Change log 编写指南

我相信你们确定仍是会疑惑。这里就以我以前理解的 commit 规范为列子。但愿起到一个抛砖引玉的做用。毕竟 commit 信息只是人为规范。不一样公司，不一样项目，不一样人有着本身的看法。由于做者自己是一名爱岗敬业的 Android 程序员，可能提交日志相对于倾向于移动端，因此若是你们有更好的提交日志分享。这里很是欢迎在评论中看到你的回答~

反面例子

在了解个人提交规范以前，咱们来看一些反面的 commit 信息：

• 修改登陆界面的Bug
• 修改空指针异常
• 增长提示
• 代码优化
• 调整UI

从上述 commit 信息中，我相信你们已经看出一些问题，就是这些 commit 消息意图都指代不明。咱们根本能从这些 commit 中知道，究竟是为了解决什么问题而提交的。

就拿 "修改登陆界面的Bug” 来讲，到底登陆界面有什么 Bug ？就不能写清楚吗？ "修改空指针异常”，哪一个界面的空指针？致使空指针的缘由，又是什么呢？

这个时候你可能会说："咱们能够查看 commit 对应所提交的文件, 你看修改的文件不就知道我干了什么吗？" 对！好像从代码中我能知道你干了什么，可是我懒啊，我不想看你写的代码，我只想知道你提交这个 commit 的原由及解决方式，对于你的代码我不想关心。

固然这并非懒不懒的缘由，一个好的 commit 就像指路牌同样，总能简单明确的告诉咱们明确的信息。特别是在项目后期维护与迭代中，咱们能也根据这些 commit 快速锁定问题。总之一个良好的 commit 有着不容小觑的做用，那接下来看看关于个人日志提交规范吧。

关于个人日志提交规范

整个信息结构由两个不一样的部分构成，这些部分由空行分割：标题、可选的消息体。

标题

消息体
复制代码

具体的结构以下所示：

类型:【项目组名称/简称】【Bug/需求Id】【有无风险】【有无依赖】【需求/Bug/更改描述】

   - 分析:
   - 风险:
   - 解决方案:
   - 测试建议:
   - 适用范围:
   - 测试机型:
   - 自测结果:
复制代码

标题

标题通常状况下，都不超过 50 个字符，末尾不加句号。若是50个字符，还不能很清楚的描述你此次的 commit 。那么你能够在消息体中具体描述。接下来咱们就分别介绍标题中涉及到的选项。

类型（必填）

类型位于在标题内，有如下几种可能：

• Feat(feature)：新功能
• Fix：bug 修复
• Docs：文档修改，注释更改
• Style：修改代码格式、补充分号等
• Refactor：代码重构
• Test：测试添加、测试重构等，代码无变更
• Chore：构建任务更新，程序包管理器配置等，代码无变更。
• Revert:恢复先前的提交

添加类型主要的目的，不只是为了帮助本身或其余人理解对应 commit 主要干了什么，还能够筛选同类型的提交。好比咱们能够筛选出全部的feat(新功能） ，那么在发布新版本的时候，咱们能更好的书写版本发布日志。

项目组名称/简称（非必填）

填写项目组名称或者简称，可是通常建议简称。这样咱们就能迅速找到该项目组提交的代码。代码若是出现了问题，咱们也能快速定位到哪一个组该背锅，你说是不？

Bug/需求 Id（必填）

Bug/需求Id 须要对应你本身的公司项目的管理工具，如 JIRA、Icafe、Teambition 等，这里将 Id 放在标题内，也是考虑到起到一个快速定位的做用，放在标题处显眼！！！

有无风险(非必填)

在实际的项目开发中，每每会涉及到系统版本兼容问题、数据库迁移问题、特定版本API使用问题、项目新老版本适配问题等其余风险。在项目开发中，咱们须要将这些风险明确指出。 若是你此次提交内容中包含一些风险因数，那么这里咱们就能够添加【有风险】，具体什么风险，咱们能够在消息体中的风险模块中具体描述。

有无依赖(非必填)

这里有无依赖是指的是否依赖其余模块，若是公司的项目很大，通常都会涉及到多模块，不一样模块之间确定会有依赖关系。这里举一个简单的例子，假如咱们开发的是一个商场项目，如今咱们是基础业务组，如今有一个需求#331，须要让咱们实现点击某个商品，完成购物，那么咱们确定会涉及到用户支付，而支付又是支付组在负责。那么在进行 commit 提交时，咱们就能够添加【依赖支付模块】，这样作不只可让咱们的测试工程师清晰的知道需求所包含的模块。也能在功能出现问题的时候，可以找准方向，对症下药。

需求/Bug/更改描述（必填）

在标题处，经过对需求、Bug、更改的简短的描述，也能快速的让其余人知道咱们这个提交究竟是作什么的。通常状况下，描述以动词开头，好比新增某个功能、移除了什么、更新了什么、重命名了什么、移动了什么等等。总之简短扼要就好了，若是你以为简短的语句，并不能很好的概况所须要解决的问题。那么你能够在消息体中在进行详细的描述。

消息体（选填）

消息体，能够看作对标题的细致描述。并非全部的提交信息都复杂到须要消息主体，所以这是选填内容，仅在提交信息须要必定的解释和语境时使用。消息体主要用于解释与完善提交任务的内容和缘由。接下来咱们就来分别讲解消息体中包含的其余选项。

分析（选填）

分析模块：主要对需求的场景分析与Bug出现的缘由进行介绍。这里分析的做用很是重要。不只能验证开发人员对功能或 Bug 的理解程度，还能减小公司新来的小伙伴阅读代码，了解业务的时间。

风险（选填）

风险模块：是对标题中的【有风险】进行详细的阐述。具体怎么描述，根据本身的实际项目而定。

解决方案 （选填）

解决方案模块：该模块主要针对于性能优化，Bug修复。主要用于解释所解决的问题的方式方法。

测试建议 （选填）

测试建议模块：该模块主要针对于新功能开发，Bug修复。在该模块中，咱们能够详细说明，有哪些界面，哪些功能须要测试。这对于采用自动化打包工具（好比 Jenkins）的 团队特别有用，由于咱们的测试小伙伴能够在使用自动化打包工具打包时，就能看见你提交的 commit ，那么根据你提供的测试建议，他们也能知道到测试过程当中须要着重测试的地方以及须要注意的地方。

适用范围 （选填）

适用范围模块：该模块主要包含的内容 取决于 commit 的内容是针对某一系统版本，针对于特定设备，仍是包含全部。这里能够根据自身的提交来填写。

测试机型(选填)

由于做者我是一名 Android 程序员，因此这里单独抽出了测试机型，也是合情合理的。

测试机型模块：该模块主要包含内容为你当前项目所运行的设备机型。固然由于 Android 的碎片化，在实际的项目开发中，咱们可能会考虑不一样厂商下的不一样手机型号下的不一样系统版本适配的问题。因此这里的机型，并非惟一值，仍是要根据自身的提交来填写。

（PS:Android 程序员就是这么辛苦，为何工资没有 IOS 的高，不开心。）

自测结果

自测结果模块：完成新功能或修改 Bug 后，填写自测结果。不只是对咱们本身工做成果的验收，还能减小由于代码的问题而增长的返工次数，虽然咱们不能保证本身测试后，就没有任何的问题了，可是至少咱们的态度是端正的对吧~

例子展现

了解了规范以后，咱们来看看经常使用的 commit 书写。

功能开发

对于功能开发，咱们通常须要标题与消息体。具体例子以下所示：

Feat:【CT】【#1345】【无风险】【无依赖】【优化了优惠券的展现方式】

   - 分析:顾客帐户的优惠券太多，若是按照原来的一个个展现，显示比较混乱。因此须要将同类型的劵合并展现。
   - 风险:无
   - 解决方案:将同类型的优惠券合并展现
   - 测试建议:测试优惠券展现界面
   - 适用范围:全部版本
   - 测试机型:oppo、miui、huawei
   - 自测结果:经过
复制代码

在该 commit 中，标题中的数据以下：

• Feat：功能类型
• 【CT】：为项目组名称/简称
• 【#1345】：为需求ID
• 【无风险】：有无风险、无则显示为无
• 【无依赖】：有无依赖，无则显示为无
• 【优惠券展现优化】：功能的简要描述，以动词开头

消息体中的数据，比较明显，这里你们能够本身的项目需求来填写。

Bug 修改

Bug 修改的 commit 信息 与功能基本开发同样，惟一的区别就是 commit 的 类型为 Fix。具体例子以下

Fix:【FS】【#123】【无风险】【无依赖】【修改登陆界面密码框输入空字符串致使的程序崩溃】

   - 分析:由于在输入密码时，没有对数据进行判空处理，因此会致使空指针异常。
   - 风险:无
   - 解决方案:对密码字符串进行判空处理，若是为空则提示用户输入密码。
   - 测试建议:对bug进行回顾测试
   - 适用范围:全部版本
   - 测试机型:oppo、miui、huawei
   - 自测结果:经过
复制代码

文档与样式修改

由于文档的编写与文档的样式修改并不会影响主体的代码，因此咱们不用像新功能开发与bug修改那样书写很完整的 commit 信息，只须要简明扼要的描述咱们修改的内容就能够了。

文档修改：

Docs: 修改了 MainActiviy 类中的方法注释
复制代码

或者

Docs: 添加了使用指南的文档
复制代码

格式样式修改：

Style:修改了 MainActiviy 类中的格式
复制代码

其余注意事项

在进行 commit 时，咱们仍然须要注意如下事项：

• 咱们须要保证对项目的 commit 是针对新增某一个功能或修复某一个Bug 所做的提交。而不是该提交中包含对其余功能模块的修改。
• 咱们尽可能建立短小而明确的 commit ，什么是短小而明确的 commit 呢？其实很简单，咱们的 commit 所涉及的文件最好不要超过10多个文件或数百行的代码更改。咱们的 commit 要有针对性。

题外话

虽然了解一个项目的最好的方式就是 read the fucking source code，可是若是项目自己有着良好的 commit ，总会给咱们带来事半功倍的效果对吧。从一些小事严格要求本身，我相信之后总会为咱们带来一些特别的惊喜~~