Git - 如何写好你的提交信息？

时间 2019-11-06

标签 git 如何写好提交信息栏目 Git 繁體版

原文原文链接

前言

平时咱们在提交的时候，确定是会对本身所作的事情作一些或多或少的说明。但怎么写好就不是那么容易了。因而就跑到github上看看人家是怎么写的，或者Google下，看看有没有什么好的实践经验。特此作了总结，但愿能抛砖引玉。css

坏栗子

咱们从坏栗子开讲，这样就有的对比了，也好对号入座。正如这个命令，10我的有9个绝对写过。html

git commit -m "Fix login bug"

咱们还会这么写。react

git commit -am "Fix login bug"

也会这样。git

git commit -am "Fix bug!"

很明显，你是在说这个提交是在修改一个登陆的BUG，由于没有拼写错误因此我能大概看明白。但我要是管理员我就难过了，会有一大堆的问题席卷而来。心理会想大哥，你修得这个BUG是哪一个？哪一个登陆的？什么样的？怎么改的？。~~而后你后脊梁骨发凉，由于有人在骂街。~~github

你也能够这么想，管理员能够耐着性子把个人修改看完，这样就不就好了？很差意思，这样的话管理员会疯的，因此不能够这么作。web

提倡的作法

粒度

说的是作的修改的粒度。若是你一天作了不少的修改，可是就只提交了一次，那么你的粒度就有点大了。这样在你描述你的行为的时候就会显得模糊，若是你详细描述的话，提交信息会变得长篇大论。但也不要作一点提交一点，这样粒度就会变得过小，会致使一天到晚在写提交信息，没有必要。shell

在我看来，这个事情真的只能凭感受提交，用经验来作判断。由于一个BUG可能可大可小，大的话，你就得分割修复。若是小，那么就一次提交修复就可。express

粒度的掌握绝对会影响你的提交信息，由于两者是一一对应的。vim

段落

还记得上学的时候，写英语做文的三段法吗？和那个差很少，开头阐明观点，中间论述观点，最后总结。
这里咱们把提交信息也分为三段，具体以下。cookie

refactor($browser): remove private polling mechanism

The only feature of Angular using this mechanism was `$cookies`,
which no longer mirrors the browser cookie values and so does not
need to poll.

Closes #11222

感受如何？该有的有，该没得没。作了什么？为何这么作？影响了什么？能够说是一目了然。

如今咱们来讲说为何这样作好。

开头

首先，开头部分单起一行，这在git中就会作为默认显示的部分，在你查看提交信息的时候就会显示这行，其余的部分则在进一步查看的时候才会显示。

你能够指定模块，或者说明动做（Add - Update - Delete）。

中间

其次，在中间的部分就是你的详细说明，这个时候就要你作一个全面的说明了。说说你大概搞了什么东西，是怎么搞的。

最后

最后的这句话有妙用，他会根据你提到的issue编号自动地关闭你的issue。固然这个和你使用的git服务端有关系，在gitlab中会用Fix来进行关闭。实现了必定的自动化，而后你的团队的成员就会受到通知，多么美好。

实际运用

三段式在一般状况下是标配，固然也有例外。在没有相关issue的时候，最后部分能够省略掉。在标题解释了全部的事情的时候，中间的部分能够省略，如你重命名了一个文件，或者是删除了一个文件的时候。因此说只写一个标题也是能够的，前提是够准确。

像是这样

Rename cropper.css -> cropper.scsss

或是

Add calendar setting file

宽度

是的，是宽度，不是长度。和代码同样，若是你平时注意的话，就不要让你的代码在一行上超过80，否则谁读代码都很差受，包括你本身。因此提交信息的宽度也有限制。

分别是标题不要超过50，内容部分不要超过70。你可能会想，写的时候还要查字数好难过。其实稍微配置一下就能够了，具体操做会在后面说道。

统一

只要统一了格式，那么团队的各位都会明白你要表达的意思，因此你彻底能够撇开上面的建议本身另起一套。

规范提交信息的格式的目的就是能快速准确的表达信息，只要达到了这个目的就能够。习惯而已。

小技巧

配置提交信息的宽度

我随时可能忘记宽度的限制，因此要作一个设置，这样就能自动的对提交信息作格式化了。对于这样的设置要取决于你的git默认选择的编辑器是什么，通常都是vim什么的。

在 ~/.vimrc 里加上下面的命令，而后就会有神奇的事情发生了。

例如我用webstorm就集成了这个功能，我也就没有太折腾。

autocmd Filetype gitcommit setlocal spell textwidth=72

不要使用 -m 或者 --message 作提交

这个命令让你可以在一次操做中就把信息提交了。看起来很好，但事实上就是这个命令让你们懒惰了。真正好的提交信息真的很难用用一句话说好，你不是在给一行代码作注释，你是在给一连串的改变作出解释。作了什么？为何这么作？影响了什么？至少得把这三个问题给回答了。当你认知在编辑器里写提交信息的时候，你会想起不少事，经验之谈。

好栗子

其实你们也是满随意的，但又很统一。

Jquery

shellCSS: Restore the hack to get pixels for .css('width') etc.

This hack turns out to be needed by Android 4.0-4.3.

Add a support test so that the hack is invoked only where needed.

Refs gh-1815
Refs gh-1820
Closes gh-1842

angular

fix(filterFilter): Fix filtering using an object expression when the …
…filter value is undefined

Fixes #10419
Closes #10424

backbone

Merge pull request #3443 from jridgewell/history-root

History's root

react

Sync out another jsx transform test.

We added this test internally and it never got added here. We haven't broken it
with any transforms *yet* but it's still good to actually run all of our tests
here too.

结语

不必定要把上面提到的全部的要求都强制的推给团队的全部人，要因地制宜，但必定要规范。正如代码的注释，合适就好。但这个合适要让人明白和清楚，没有额外的废话。

没有最好的，只有合适的。

望你们看完能够作点评。