wordpress文章来源信息谷歌优化培训
文章目录
- 前言
- git commit 提交规范
- 提交消息头(commit message header)
- 提交消息具体内容(commit message body)
- 提交消息尾述(commit message footer)
- Revert
- 表情(Emojis)标识
- idea插件
- 其他操作
- Commitizen
- 生成 Change log
- Git获取提交消息格式化输出
- 相关参考
前言
我们都知道，Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交，这其实就是规范，但输入的说明我们可以随便写。
无规矩不成方圆，当查看git提交历史的时候，发现每个人git的提交记录都有自己的风格和习惯，并没有一套完整的规范，不利于阅读和维护。所以需要一套git提交规范，使得提交记录清晰明了，让人一看就能知道此次提交的目的。
git commit -m "hello world"
上面代码的-m参数，就是用来指定 commit mesage 的。
如果一行不够，可以只执行git commit，就会跳出文本编辑器，让你写多行。
git commit
一般来说，commit message 应该清晰明了，说明本次提交的目的。而且多人协作的时候，有问题也方便查看提交日志。
git commit 提交规范
Conventional Commits 是由众多开源项目贡献者共同约定的一个规范，用来约定 Git Commit 内容的书写方式，让 commit 内容更有价值、条理，使提交历史明确可追溯。
格式如下：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
提交消息的任何一行都不能超过100个字符！这使得消息更容易在github以及各种git工具上阅读。
提交消息由页眉、正文和页脚组成，由空行分隔。
提交消息头(commit message header)
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
（1）type
type用于说明 commit 的类别，
常用的标识如下：
| 类型 | 描述 |
|---|---|
| feat | 新功能（feature） |
| fix | 修补bug |
| docs | 文档（documentation） |
| style | 格式修改（不影响代码运行的变动） |
| refactor | 重构（即不是新增功能，也不是修改bug的代码变动） |
| test | 增加测试 |
| chore | 构建过程或辅助工具的变动，非src和test的修改，比如构建流程, 依赖管理等 |
| perf | 性能优化(performance) |
| improvement | 改进 |
| build | 打包 |
| ci | 持续集成 |
| revert | 撤销，版本回退 |
如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。
（2）scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
（3）subject
subject是 commit 目的的简短描述，不超过50个字符。
- 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
- 第一个字母小写
- 结尾不加句号（.）
提交消息具体内容(commit message 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
有两个注意点。
（1）使用第一人称现在时，比如使用change而不是changed或changes。
（2）应该说明代码变动的动机，以及与以前行为的对比。
提交消息尾述(commit message footer)
Footer 部分只用于两种情况。
（1）不兼容变动
如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。
BREAKING CHANGE: isolate scope bindings definition has changed.To migrate the code follow the example below:Before:scope: {myAttr: 'attribute',}After:scope: {myAttr: '@',}The removed `inject` wasn't generaly useful for directives so there should be no code using it.
（2）关闭 Issue
如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。
Closes #234## 也可以一次关闭多个 issue
Closes #123, #245, #992
Revert
还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。
revert: feat(pencil): add 'graphiteWidth' optionThis reverts commit 667ecc1654a317a13331b17617d973392f415f02.
Body部分的格式是固定的，必须写成This reverts commit <hash>.，其中的hash是被撤销 commit 的 SHA 标识符。
如果当前 commit 与被撤销的 commit，在同一个发布（release）里面，那么它们都不会出现在 Change log 里面。如果两者在不同的发布，那么当前 commit，会出现在 Change log 的Reverts小标题下面。
表情(Emojis)标识
styleguide-git-commit-message
idea插件
知道了提交的规范，但是经常记不住格式怎么办？
可以借助强大的idea插件Git Commit Message Helper;
其他操作
Commitizen
Commitizen是一个撰写合格 Commit message 的工具。
安装命令如下。
npm install -g commitizen
然后，在项目目录里，运行下面的命令，使其支持 Angular 的 Commit message 格式。
commitizen init cz-conventional-changelog --save --save-exact
以后，凡是用到git commit命令，一律改为使用git cz。这时，就会出现选项，用来生成符合格式的 Commit message。
生成 Change log
conventional-changelog就是生成 Change log 的工具。
Git获取提交消息格式化输出
//1. 获取提交列表message headergit log <last tag>..HEAD --pretty=format:%s或者git log <last tag>.. --pretty=format:%// 2. 过滤 类型 typegit log <last tag>..HEAD --grep feature// 3. 跳过一些无关紧要的提交git bisect skip $(git rev-list --grep <pattern> <last tag>..HEAD)
相关参考
以下是搜集了关于提交规范比较好的资源，方便自己和大家参考：
阮一峰的网络日志 - Commit message 和 Change log 编写指南
AngularJs Commit说明
Google Doc - AngularJS Git Commit Message Conventions