一个建议：
配置commit template，每次commit 都记录本次修改的主要内容。
举例1：（简单）
$ vim .commit_template
Feature:/
BugId:/
Description:
举例2：(推荐)
$ vim .commit_template
# type(<scope>): <subject>
# <body>
# <footer>
# type字段
# type用于说明 commit 的类别，只允许使用下面7个标识。
# * feat：新功能（feature）
# * fix：修补bug
# * docs：文档（documentation）
# * style： 格式（不影响代码运行的变动）
# * refactor：重构（即不是新增功能，也不是修改bug的代码变动）
# * test：增加测试
# * chore：构建过程或辅助工具的变动
#
# scope字段
# scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
#
# subject字段
# subject是 commit 目的的简短描述，不超过50个字符。
# * 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
# * 第一个字母小写
# * 结尾不加句号（.）
#
# body字段
# Body 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。
# More detailed explanatory text, if necessary. Wrap it to
# about 72 characters or so.
#
# Further paragraphs come after blank lines.
#
# - Bullet points are okay, too
# - Use a hanging indent
#
# footer字段
# Footer 部分只用于两种情况。
# - 不兼容变动；
# - 关闭 Issue
#
git config commit.template .commit_template
或者
git config --global commit.template .commit_template
template 可以自行定义，也可以团队约定（建议）。
https://www.zhihu.com/question/61283395/answer/186122300
vue 提交记录：
可以借鉴的commit message:
angular的github仓库；
https://github.com/angular/angular
vue 的github 参考；
NOTE: 个人还是更喜欢angular的commit message 风格。
扩展阅读
git commit中输入message的几种方式
http://www.jianshu.com/p/ad461b99e860
简介：
这里提到了git message 的几个有意思的小技巧，但不是规范提交所推荐的...
在所有的git教程里，git commit肯定是一开始就会提到的命令。一般情况下每个commit都会有一段commit log message。message可能有一行内容，可能有多行内容，中间可能会有空白行。在第一个空白行前面的部分称为subject，之后的部分称为body。subject和body在git log或者git show的输出format中分别可以用%s和%b获得，也可以用%B同时获得subject和body，等价于%s%b。在进行项目开发的时候，事先约定好message的格式并且让大家都遵守这个约定，是比较好的做法。在用git commit生成一个commit的时候，message的输入方法有很多种：
1. 最常见的做法是用-m <msg>参数，等价于--message <msg>。在message只有一行内容时，用这种方式比较方便，但如果要输入很多行的话，就不是那么方便了。
git commit -m 'hello world'
2. 第二种做法是什么参数都不要带，直接就用git commit。这会启动文本编辑器，打开.git/COMMIT_EDITMSG，在里面输入想要的message，然后保存退出就可以了。这种方式非常自由灵活，想要什么输入什么。
git commit
3. 人总是趋向于偷懒的，每次都要手动输入一堆东西肯定嫌烦。那有没有办法可以利用现有资源呢？git commit提供了一个-c <commit>，等价于--reedit-message=<commit>，还有个差不多的-C <commit>，等价于--reuse-message=<commit>。这种做法会重用<commit>的message，将其原封不动地利用起来，只要是当前git中已经存在的commit就可以，不存在的话可以先从其他地方fetch过来。-c，reedit，会启动文本编辑器，让用户可以重新编辑；-C，reuse，不给用户重新编辑的机会，相当于-c <commit> --no-edit。重用是很方便，但这种做法不仅仅重用了message，连author和date也一起重用了，除了commit id不一样，其他都一样，一看就是抄来的。所以我们最好再加上--reset-author参数，这么做会使用当前的author和date。
git commit -c HEAD --reset-author
4. git commit还提供了从文件中读取message的方法，-F <file>，等价于--file=<file>。这不会启动文本编辑器，直接将<file>中的内容全部拿过来当作message，包括以#开头的行。本来.git/COMMIT_EDITMSG中以#开头的行都算是注释，不会被添加到message中去的。这时我们再用git commit --amend，什么都不改，保存退出的话，那么以#开头的内容就都从message中消失了。<file>可以是标准输入，用“-”来表示。譬如echo "hello world" | git commit -F -。
echo "hello world" > hw && git commit -F hw
5. git commit中并没有像-c和-C那样提供一个-f <file>来让用户reedit这个file，而是用了-t <file>，等价于--template=<file>。这会启动文本编辑器，已有的内容是<file>中的内容，用户可以进行编辑之后保存退出。用户如果没有做什么修改的话，或者修改完后内容没变的话，commit不会成功。如果想要偷懒一点的话，可以用git config设置下commit.template，给其指定这个template file，指定完以后就不用每次都输入-t <file>了。如果用了-c，-C或者-F的话，那么-t <file>和commit.template是不会起作用的。template的方式比较适合用于事先约定好message格式的场景，把格式的固定内容都放在template中，用户commit的时候把其余部分填写完整就可以了。
echo "hello world" > hwt && git commit -t hwt
6. 如果懒得什么message都不想写！那用--allow-empty-message就可以了，但你确定要这么做吗？
echo "I am a git" && git commit --allow-empty-message --no-edit
7. 如果你拒绝使用--allow-empty-message，但又不想写commit log message的话，那就安静地做个integrator吧。用git merge，git rebase，git cherry-pick，git am，都是体贴你的小棉袄，但一定要拒绝git apply，因为它会要你写message的。
8. 亲手试一下每种方式吧！如果觉得每次要做点修改或者新增个文件才能add、commit很麻烦的话，那就加上--allow-empty吧，什么文件都不用改，也不用git add，直接就可以commit了！如果不想在尝试的时候生成一长串无用的commit的话，那在有root commit的情况下再加上个--amend吧，改来改去都只有一个commit。
echo "I love git" && git commit --allow-empty --amend
作者：ElpieKay
链接：http://www.jianshu.com/p/ad461b99e860
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
Git commit template 模板设定
http://blog.csdn.net/aaa2832/article/details/7746610
一个转发地址：
http://www.cnblogs.com/lookphp/p/5167180.html
简介：
一个示例模板：
OverView：
BUG：
Description：
Commit message 和 Change log 编写指南
http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html
一个备份地址：
http://yulijia.net/cn/%E6%A0%BC%E5%BC%8F%E6%8A%80%E5%B7%A7/2016/01/21/git-commit-style.html
简介：
阮一峰 的博客。
目前，社区有多种 Commit message 的写法规范。本文介绍Angular 规范（见上图），这是目前使用最广的写法，比较合理和系统化，并且有配套的工具。
AngularJS Git Commit Message Conventions
https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#heading=h.greljkmo14y0
简介：
Angular 的提交规范。
阮一峰 的博客提到的。
https://github.com/sparkbox/standard/blob/master/style/git/.gitmessage
使用 "5W1H" 写出高可读的 Git Commit Message
https://zhuanlan.zhihu.com/p/26791124
一个备份地址：
https://juejin.im/post/59110c322f301e0057e4c182
简介：
git commit message 的插件：
插件：
用 webstorm 的朋友安装 commit message template 插件。
Github上git commit 提交注释的规范
https://segmentfault.com/q/1010000000395039
简介:
git commit 提交规范。
一般情况下，提交 GIT 时的注释可以分成几类，可以用几个动词开始：
Added ( 新加入的需求 )
Fixed ( 修复 bug )
Changed ( 完成的任务 )
Updated ( 完成的任务，或者由于第三方模块变化而做的变化 )
尽量将注释缩减为一句话，不要包含详细的内容。
假如有 Issues 系统，其中可以包含 Issue 的 ID。比如：Issue #123456
包含作者的信息。比如 by Bruce
完整例子：
git commit -m 'Issue #[issue number] by [username]: [Short summary of the change].'
Related articles
另一个：
Mod: remove unused code, 表示修改（Modify）
Add: a new module to have faster process, 表示新增（Add）
Rem: deprecate unused modules, 表示移除（Remove）
Ref: improved the implementation of module X, 表示重构（Refactory）
有同学要问了：如果一个commit里的内容无法用上述任意一种语句陈述，应该怎么办？
同学，那说明你的commit应该被拆分成多个小部分
当然我最喜欢的commit message还是第一个commit，内容是 First Blood
Git 写出好的 commit message
https://ruby-china.org/topics/15737
简介：
一些规范要求：
第一行应该少于50个字。 随后是一个空行 第一行题目也可以写成：Fix issue #8976
喜欢用 vim 的哥们把下面这行代码加入 .vimrc 文件中，来检查拼写和自动折行
autocmd Filetype gitcommit setlocal spell textwidth=72
永远不在 git commit 上增加 -m <msg> 或 --message=<msg> 参数，而单独写提交信息
一个不好的例子 git commit -m "Fix login bug"
一个推荐的 commit message 应该是这样：
Redirect user to the requested page after login
https://trello.com/path/to/relevant/card
Users were being redirected to the home page after login, which is less
useful than redirecting to the page they had originally requested before
being redirected to the login form.
- Store requested path in a session variable
- Redirect to the stored location after successfully logging in the user
注释最好包含一个连接指向你们项目的 issue/story/card。一个完整的连接比一个 issue numbers 更好
提交信息中包含一个简短的故事，能让别人更容易理解你的项目
