Git commit提交规范

目前工作中master上的提交点比较乱，同时每个提交的描述信息也没有统一的规范，提交信息乱，同时其他人无法从提交点知道该提交点具体做了哪些事情，也不利于后续跟踪功能点。

这里提一点就是我们在合并我们的分支到主分支的时候一定要先检出一个新分支出来，变基然后合并到主分支！

Commit Message 规范

目前市面上有多种Commit Message规范，其中
Angular 规范
规范是目前使用最广泛的，在我们规范我们提交描述的前期可以先使用现有成熟的方案，在使用中来根据实际情况再来进行调整。

我们先来看看GitHub上Angular和Vue的提交信息：

Vue

angular

上面第一张图是Vue的提交点，第二张图是Angular的提交点。其实我们可以看出，他们之间还是很相似的，或者说他们的Commit Message规范是很相似。相对于我们现在的主分支提交信息，他们的提交点的说明，是可以让我们没参与开发的人一眼能够打开看出他们在某个提交点做了哪些事情的。

Angular Commit Message 格式

Angular的规范里面，每次的提交信息规范的文本格式为：

angular commit message

上图以后我们会经常看到，这是prepare-commit-msg-dianwoda插件在每次我们git commit时显示出来的提示信息。

<type>(<scope>): <subject> // header
// 空一行
<body>
// 空一行
<footer>

Header部分只能写一行，当我们用单行模式查看log记录的时候展示的就是这一行。

1.type（必须）

type用于说明commit类别，必须是下面8种中的一种：

1.feat：新功能（可以出现在CHANGELOG中）；
2.fix：解决bug（可以出现在CHANGELOG中）；
3.docs：文档的修改
4.style：代码格式的修改
5.refactor：重构（既没有改bug也没有开发新功能）
6.perf：性能优化（可以出现在CHANGELOG中）；
7.test：增加测试
8.chore：构建过程或者辅助工具的变动

2.scope（可不填）

scope用于说明commit的影响范围，像Angular是针对$location, $compile…等，而我们的项目中可以根据功能的不同来指定。比如从U享版开始我就将内嵌页的各项功能做成了多入口的模式，每个功能都是一个单独SPA，那这样的话比如我们在进行提交时就是在scope指定我们的功能模块比如：feat(space): 收藏夹…。

3.subject（必须）

subject是对本次commit的简短描述。angular对这个如何编写也做了描述，不过我们不会用英文进行描述，所以他们的规则对我们不适用。

Body

Body部分是对本次commit的详细描述，这个可以分成多行进行：

feat($browser): onUrlChange event (popstate/hashchange/polling)

Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available

BREAKING CHANGE: $browser.onHashChange, which was removed (use onUrlChange instead)

在我们实际开发中我们可以详细的记录参与此次提交功能相关的所有的人：前后端开发，产品，测试等，我们功能的入口，产品文档地址等信息。

Footer部分值能用于两种情况：

1.不兼容变动

如果当前代码功能和上一个版本的功能不兼容，则在Footer部分已BREAKING CHANGE开头，后面是对变动的描述、变动理由和迁移方法。可以参考Body样例底部BREAKING CHANGE

2.关闭Issue/Bug

如果当前提交是为了关闭某个bug，可以在Footer部分关闭：

1	fix: #123, #234

Revert

我们在开发时，可能会碰到某个功能要下架的情况。这种情况的commit必须以revert：开头，后面跟着被撤销提交点的Header。

1
2
3

rever: feat(space): 收藏夹...

This reverts commit <SHA hash> // Body部分是固定的，必须写成这样，后面跟的是被撤销提交点的SHA值

commitlint & husky

我们确定了规则之后，我们如何应用起来呢？我们有了规则如何进行约束大家呢？

我们如果能够在每次commit的时候对我们的提交信息进行校验的话，就能有效监控大家的提交点是否符合规范了。

commitlint和husky(哈士奇)就隆重登场了。

commitlint：是对我们的commit message进行校验的插件，我们安装@commitlint/config-conventional这个符合Angular规范的插件，就可以完成我们的校验配置了。

husky：哈士奇这款插件是用来在运行git commit 和 git push 等命令时，获取对应的工作流钩子Git hooks来执行我们指定的行为。

{
  ...
  "scripts": {
    "cm": "git-cz",
    "precommit": "lint-staged",
    "preparecommitmsg": "prepare-commit-msg-angular",
    "commitmsg": "commitlint -e $GIT_PARAMS",
    "release": "standard-version"
  },
  "devDependencies": {
    "@commitlint/cli": "^6.1.3",
    "@commitlint/config-conventional": "^6.1.3",
    "commitizen": "^2.9.6",
    "cz-conventional-changelog": "^2.1.0",
    "husky": "^0.14.3",
    "lint-staged": "^7.0.0",
    "prepare-commit-msg-angular": "^0.2.0"
  },
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
  },
  "lint-staged": {
    "*.{vue, js}": [
      "eslint --fix", // 对vue和js文件进行格式检测并进行修复
      "git add" // 将进行了格式修复的文件加入暂存区，不会新起一个提交点
    ]
  }
}

上面是一份package.json文件的片段。我们先关注scripts中的这几个命令：

precommit: 这是husky的一个钩子——pre-commit，对应的是我们git commit键入提交信息前的行为，这里指定了lint-staged这个插件，这这一步往往做的都是格式检查，我们在开发中把格式检查关闭了，当时伟集是因为开发时实时监测影响开发效率，这里转成在提交时进行自动格式修复可能会好点（这里还需要实践）；
perparecommitmsg: 这也是一个husky的钩子——perpare-commit-msg，对应的是启动提交信息编辑器之前，默认信息被创建之后运行。也就是说我们在这时运行perpare-commit-msg-angular这个插件，也就是我们上面看到的显示angular提交规范文本覆盖了默认commit文本；
commitmsg：对应commit-msg，这个用来在提交点的描述文本通过前来进行校验，判断是否符合规定，如果不符合规定则以非零值退出，放弃此次提交。

这样一来我们在执行git commit时，如果提交信息不符合规范，则会终止提交。

Commitizen

在上面的配置中有这么一句：cm: git-cz

这是Commitizen插件的简写，它提供了一种交互式的写法，让我们按照它的提示去写提交信息，这样更容易让我们养成按规范些的好习惯。

这样一个交互界面，在前期我们不太熟悉规范的情况下，每一项都有提示填写。如果我们要使用这种方式的话，不能直接用npm run commit，需要使用npm run cm，之所以要这样写是因为这是husky的一个bug，当然我们直接用git cz去运行也可以。

不过这样写有一个问题就是它是先填写了提交信息，然后husky再执行一系列的检测任务，如果我们以后再lint-staged里面加上了其他的检测任务的话，遇到错误就终止提交了，我们相当于前面的提交信息白写了。

conventional-changelog/standard-version

上面的配置中有这样一句“release”: “standard-version”，这是一个生产CHANGELOG.md文件的插件。我们在前面有提到feat fix perf这些是会出现在CHANGELOG中的，我们可以通过这个插件来生产我们主分支上的日志信息，因为我们每一次提交都详细的描述了我们在本次提交中开发涉及的东西，比如参与人员，产品文档，功能入口等信息，这样一来就相当于我们之前讨论的维护一份功能清单，方便我们进行查找各个功能。

我们主分支下运行npm run release时，会自动创建一个CHANGELOG.md文件，文件内容如下：

我们可以看见这里分成了新特性和bug修复，当我们要找寻某个功能的信息时，我们通过Features下去查找对应的提交点，提交点后面跟着的是SHA值，我们通过查看提交点的详细信息，只要我们当初详细记录了这些信息。

这里需要注意的是，当我们运行npm run release时，它会自动创建一个提交点chore(release):x.x.x，因为它修改了CHANGELOG.md这个文件。

另外当我们查看GitHub上的release记录时，可以看到他们直接展示了很多的信息：

这是GitHub提供的功能，GitLab上也有，不过这个要在他们的web端去填表格实现，暂时还没找到集成到我们开发环境的方法。