02-commit message提交说明信息的格式

如何编写提交消息：(7条规则)
https://chris.beams.io/posts/git-commit/
参考：提交消息和更改日志编写指南:（格式）
http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html

提交信息的格式：
每次提交，提交消息都包括三个部分：Header标题，Body可选的正文 和 Footer可选的页脚。【类型：主题； 消息正文； 注释】

< type消息的类型>(< scope>): < subject主题>

type（必需）:用于说明 commit 的类别，只允许使用下面7个标识之一。

• feat：新功能（feature）

Create write support
Add commit function

• fix：修补bug

Fix typo in introduction to user guide
修正用户指南简介中的打字错误
如果读者想知道错字是什么 简单地查看一下更改本身，即 git show或git diffor git log -p。

该 commit 的feat或fix将肯定出现在 Change log 之中

• docs：文档修改（documentation）

Update getting started documentation
更新入门文档
Update rakefile
Add todo file
Update readme

• style： 格式、分号或半冒号缺失等，代码无变动
• refactor：生产代码重构（即不是新增功能，也不是修改bug的代码变动）——重构是清理代码以使其更精简和更高效，并且在不影响代码的外部功能的情况下整体改进代码的设计。一些重构 Python 代码的好例子：https://docs.microsoft.com/en-us/visualstudio/python/refactoring-python-code?view=vs-2019

Refactor subsystem X for readability
重构子系统X以提高可读性

• test：测试添加、测试重构等，生产代码无变动

Merge branch ‘experiment’
Commit the todo

• chore：构建过程或辅助工具的变动：构建任务更新、程序包管理器配置等，生产代码无变动。

Remove deprecated methods
删除不推荐使用的方法
Release version 1.0.0
发行版本1.0.0
Update the footer to copyright information
将页脚更新为版权信息

由你决定，要不要放入 Change log，建议是不要。

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

subject（必需）:是 commit 目的的简短描述，不超过50个字符。解释提交的作用（不是如何更改或为何更改！）

• 以动词开头，使用第一人称现在时，比如change，而不是changed或changes。 命令式语气
• 以大写字母开头且不以句号结尾
• 如果您很难进行汇总，则可能一次提交了太多更改。争取原子提交（单独发布的主题）。https://www.freshconsulting.com/atomic-commits/

// 空一行

分隔总结与主体的空行十分重要（除非你完全忽略主体）；否则log、 shortlog 和 rebase 等多个工具容易发生混淆。

< body可选>

任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。 正文：解释一次提交的 **内容(与以前行为的对比)** 和 **原因(代码变动的动机)** ，而不是方式。

并非所有提交都足够复杂到足以保证有一个正文，因此它是可选的，仅在提交需要一些说明和上下文时才使用。

• Git从不自动换行。在编写提交消息的正文时，必须注意其右边距，并手动换行。
• 建议使用72个字符，以便Git有足够的空间缩进文本，同时总体上将所有字符保持在80个字符以下。
• 一个好的文本编辑器可以为您提供帮助。配置Vim很容易，例如，在编写Git提交时将文本包装为72个字符。
• • -要点也可以
• • -使用悬挂缩进
• 解释该提交信息所解决的问题，说明你进行该变动的原因，而不是方法（代码本身可以解释方法）。该变动是否存在副作用或其他直觉性后果？
• 后续段落前需加空行。 可以列出要点 - 通常情况下，要点会使用空格加上连字符或星号，中间用空行分隔，但该规定存在差别。

// 空一行

< footer可选>

页脚是可选的，用于引用问题跟踪者ID。

提交消息示例

详见：https://udacity.github.io/git-styleguide/

> feat: Summarize changes in around 50 characters or less
> 
> More detailed explanatory text, if necessary. Wrap it to about 72
> characters or so. In some contexts, the first line is treated as the
> subject of the commit and the rest of the text as the body. The 
> blank line separating the summary from the body is critical (unless
> you omit the body entirely); various tools like `log`, `shortlog` 
> and `rebase` can get confused if you run the two together.
> 
> Explain the problem that this commit is solving. Focus on why you 
> are making this change as opposed to how (the code explains that). 
> Are there side effects or other unintuitive consequenses of this 
> change? Here's the place to explain them.
> 
> Further paragraphs come after blank lines.
> 
>  - Bullet points are okay, too
> 
>  - Typically a hyphen or asterisk is used for the bullet, preceded    
>    by a single space, with blank lines in between, but conventions   
>    vary here
> 
> If you use an issue tracker, put references to them at the bottom,
> like this:
> 
> Resolves: #123 
> See also: #456, #789