关于项目 git 协作流程的思考

在项目开发的过程中，由于有多人参与，每个人的习惯也不尽相同，容易导致很多不可控的问题出现。

业务代码层面，可以通过使用各种 lint 工具来约束编码规范，但是代码提交、发版等等相关的规范化一直没有强力的推动下去。

目前在开发过程中，对于分支的管理，主要参考 git flow 的规范，使用 rb-xxx 分支来作为开发分支，合并到 master 分支后由 jenkins 自动的打 tag，然后触发构建。

前一段时间开始尝试使用 commitizen 来规范化 git 的提交记录，但是仅仅就是提交的时候用一下，并没有和整个项目的管理流程相串联起来，

最近抽空重新梳理学习了一下相关的工具，主要就是：

• 使用 commitizen 辅助 git 规范化提交
• 使用 Commitlint 和 husky 来触发钩子并校验提交是否规范。
• 使用 standard-version 来自动发版并生成 CHANGELOG.md 文件。

这里有一篇别人写的挺不错的文章：优雅的提交你的 Git Commit Message

具体的某个工具的用法可以直接去 github 上看官方文档。

一、工具介绍

1. commitizen

commitizen 将 git commit 的内容规范了一下，包含了改动的类型、摘要、详细描述、影响的 issue 等等，也为后续自动生成 README.md 文件提供了基础。

本次提交的类型感觉有点不太好区分，比如某行文案更改了，是算作 feat、fix 还是 refactor 呢？

如果不好权衡选择的话，可以参考下 angular 官方仓库的提交记录：https://github.com/angular/angular/commits/master

2. commitlint 和 husky

commitlint 可以配合 husky 在 git commit 之后触发检查，如果不符合要求的话，提交无效。

3. standard-version

standard-version 是单独用一次 git 提交来修改 CHANGELOG.md 文件并打 tag，但是由于目前团队内的项目采用的是提前确定好下次发布的版本号之后，建立相应的 rb-xxx 分支，然后合入 master 之后，jenkins 自动打 tag ，所以不太适用 standard-version。

使用 git log 查看：

二、使用方法

1. 配置 commitizen

yarn add -D commitizen cz-conventional-changelog 

package.json 文件中加入：

"scripts": {
    ...,
    "commit": "git-cz",
},
"config": {
    "commitizen": {
        "path": "node_modules/cz-conventional-changelog"
    }
}

2. 配置 commitlint 和 husky

commitlint：

yarn add -D @commitlint/config-conventional @commitlint/cli

在项目目录下创建 .commitlintrc.js 文件并写入：

module.exports = {
  extends: [
    '@commitlint/config-conventional'
  ],
  rules: {
  }
};

husky：

yarn add -D husky

package.json 文件中加入：

"husky": {
    "hooks": {
      ...,
      "commit-msg": "commitlint -e $GIT_PARAMS"
    }
  },

3. 配置 standard-version

yarn add -D standard-version

package.json 文件中加入：

"scirpts": {
    ...,
    "release": "standard-version"
}

二、一点心得

如果要将所有工具都串联起来使用的话，感觉可以尝试还是使用 development 分支作为开发分支，然后日常提交使用 commitizen，某个版本迭代完成之后，将 devlopment 分支合并入 master 分支。

然后由管理员手动执行 standard-version 命令来完成一次 release 的提交并更新 CHANGELOG.md 及打 tag，然后直接 push 到远端 master 分支中，此时 master 分支不再触发正式环境的构建任务，改由 tag 来触发。

或者以上 release 的流程在 dev 分支合并入 master 后，由 jenkins 或 gitlab ci 来自动完成。