Git 提交规范及其在项目里的使用

git提交规范

目前最受开发人员肯定的规范是Angular提出的Angular 提交信息规范

提交格式如下

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

每次提交可以包含页眉(header)、正文(body)和页脚(footer)，每次提交必须包含页眉内容

每次提交的信息不超过100个字符

详细文档：AngularJS Git Commit Message Conventions

页眉设置

页眉的格式指定为提交类型(type)、作用域(scope，可选)和主题(subject)

提交类型

提交类型指定为下面其中一个：

build : 对构建系统或者外部依赖项进行了修改
ci : 对CI配置文件或脚本进行了修改
docs : 对文档进行了修改
feat : 增加新的特征
fix : 修复bug
pref : 提高性能的代码更改
refactor : 既不是修复bug也不是添加特征的代码重构
style : 不影响代码含义的修改，比如空格、格式化、缺失的分号等
test : 增加确实的测试或者矫正已存在的测试
chore : 构建过程或辅助工具的变动

作用域

范围可以是任何指定提交更改位置的内容

主题

主题包括了对本次修改的简洁描述，有以下准则

使用命令式，现在时态：“改变”不是“已改变”也不是“改变了”
不要大写首字母
不在末尾添加句号

正文设置

和主题设置类似，使用命令式、现在时态

应该包含修改的动机以及和之前行为的对比

页脚设置

Breaking changes 破坏性改动

不兼容修改指的是本次提交修改了不兼容之前版本的API或者环境变量

所有不兼容修改都必须在页脚中作为中断更改块提到，以 BREAKING CHANGE: 开头，后跟一个空格或者两个换行符，其余的信息就是对此次修改的描述，修改的理由和修改注释

BREAKING CHANGE: isolate scope bindings definition has changed and
    the inject option for the directive controller injection was removed.

    To migrate the code follow the example below:

    Before:

    。。。
    。。。

    After:

    。。。
    。。。

    The removed `inject` wasn't generaly useful for directives so there should be no code using it.

引用提交的问题

如果本次提交目的是修改issue的话，需要在页脚引用该issue

以关键字Closes开头，比如

Closes #234

如果修改了多个bug，以逗号隔开

Closes #123, #245, #992

回滚设置

当此次提交包含回滚(revert)操作，那么页眉以"revert:"开头，同时在正文中添加"This reverts commit hash"，其中hash值表示被回滚前的提交

revert:<type>(<scope>): <subject>
<BLANK LINE>
This reverts commit hash
<other-body>
<BLANK LINE>
<footer>

在项目里的设置 `simple-git-hooks`

将 simple-git-hooks 添加到项目中

bash

npm install simple-git-hooks --save-dev

将simple-git-hooks添加到您的package.json中。用 git hooks 和相应的命令填充它。

例如：

package.jsonjson

{
  "simple-git-hooks": {
    "pre-commit": "npx lint-staged",
    "pre-push": "npm run format",

    // 默认情况下，所有未使用的钩子将被自动删除
    // 但你可以使用 preseruunused 选项来防止这种行为

    // 如果您希望保留所有未使用的钩子
    "preserveUnused": true,

    // 如果您希望保留特定的未使用的钩子
    // "preserveUnused": ["commit-msg",],
  },
}

此配置将在每次commit时运行所有 linter，并在push时运行格式化程序。

可以配合 eslint 在提交时自动格式化代码

package.jsonjson

{
  "simple-git-hooks": {
    "pre-commit": "pnpm lint-staged",
  },
  "lint-staged": {
    "*": "eslint --fix",
  },
}

Git 分支

各分支说明

一般都有一些规范来创建分支

production 分支
一般是 master 分支，这个分支是最近的部署到生产环境的代码。这个分支只能从其他分支合并，不能直接在此分支修改代码。
develop 分支
这个分支一般是开发主分支，包含所有要发布到下一版本的 release 代码，这个分支主要合并其他分支，如 feature 分支
feature 分支
这个分支主要用来开发一个新的功能，一旦开发完成并且合并如 develop 分支进入下一个 release
release 分支
当需要发布一个新的 release 的时候，我们基于 develop 分支创建一个 release 分支，完成 release 后，我们合并到 master 和 develop 分支
hotfix 分支
当我们在 production 分支发现新的 bug，我们需要创建一个 hotfix，完成 hotfix 后，我们合并回 master 和 develop 分支，所以 hotfix 的改动会进入下一个 release

各分支操作示意图

master/develop 分支
所有在 master 分支上的 commit 应该打上 tag，一般情况下 master 不存在 commit ，develop 分支基于 master 分支创建。
feature 分支
feature 分支做完后，必须合并回 develop 分支, 合并完分支后一般会删除这个 feature 分支，毕竟保留下来意义也不大。
release 分支
release 分支基于 develop 分支创建，打完 release 分支之后，我们可以在这个 release 分支上测试，修改 Bug 等。同时，其它开发人员可以基于 develop 分支新建 feature (记住：一旦打了 release 分支之后不要从 develop 分支上合并新的改动到 release 分支)发布 release 分支时，合并 release 到 Master 和 develop，同时在 Master 分支上打个 Tag 记住 release 版本号，然后可以删除 release 分支了。
hotfix 分支
hotfix 分支基于 Master 分支创建，开发完后需要合并回 Master 和 develop 分支，同时在 Master 上打一个 tag。