【Git】怎么样才是好的提交

（点击上方公众号，可快速关注）

使用git时，不同人对提交（commit）的粒度都有自己的把控，当然这里面有一些主观的成分在里面，但有一些通用的规则是值得借鉴的。下面是我从一本关于git的英文书籍里看到的，觉得很好很实用，分享给大家。

每个提交只做一个更改（change）

这并不是说只改动一个地方；代码实现里，我们经常要改动很多地方，改动基本不可能只有一个地方。这里强调的不是改动的量，而是说所有的改动都围绕一个主题，这样的改动被认为一个更改，毕竟change在英文里的表示较大的变化。

这里有两条建议可以达成这个目的：

• 将特性（feature）和任务（tasks）分支分开

• 编码之前写好提交的消息

在一个提交里包含完整的更改（change）

这条跟上面那条类似，但强调点不同。git不是备份工具，最终提交是给人读的，若更改分布在几条提交里，不利于后续跟踪。

描述更改本身，而不是更改涉及的内容

这条是关于提交消息的。很多人提交消息写了好多实现细节，不能一目了然地看出到底提交是做了啥。在写提交消息时，要使用简短的句子，并用命令语气，比如修复、添加、实现等，描述改动；若有必要的话，在其他行添加一些细节的描述。

不要害怕提交

前几天看的新闻里，有个4岁的女孩给Linux内核提交了一个PR，只涉及到一个-符号，很多人可能嗤之以鼻，但这的确改善了内核的质量，不论大小，所以我们要勇于提交。

你提交地越频繁，你每次的提交就会越小，同时也利于阅读和理解更新日志。而且对于提交的挑拣（cherry-pick）和代码评审都是好的。

隔离无意义的（meaningless）提交

这里的无意义指的是一些关于清理的改动，如删除老的注释、格式改动、删除老的废弃代码等。

若将这些提交与其他提交混在一起，其他开发者在查看变更时可能不能很好地理解变更。举例来说，如果本次改动实现了邮件的过滤逻辑，但同时删掉了一些老的代码，这个时候，在提交时只提了邮件过滤的事，而没提到删除老代码，其他人可能不明白邮件过滤逻辑跟删除那些代码有啥关系。即使提到了，也不确定是不是所有删除的代码都跟邮件过滤逻辑无关。

书写规范的提交消息

• 主题要有意义，50字内，不要太长

• 必要时，添加其他行用于辅助说明

  通常与主题用空行间隔，分条描述，每条用短横杠开头，不超过72个字

• 附其他有用信息

  若你在用一些项目跟踪系统（比如，禅道）时，可能会有编号对应事务或bug，可以在提交内容里体现，举例如下：

  Add the newsletter signup in homepage

  - Add textbox and button on homepage

  - Implement email address validation

  - Save email in database

  #FEAT-123: closed

• 发布的消息要特殊对待

  发布跟其他更改不同，要区别对待，这也是为了能更快的找到它们 -- 很多工作流都会涉及到从发布版本建立分支。为了突出其特殊性，可以使用git tag命令。

喜欢我的文章，请关注我的公众号。