乐趣区

关于git:拜托别瞎提交代码了看人家-Git-提交规范那叫一个舒服

jiezi

git 是当初市面上最风行的版本控制工具，书写良好的 commit message 能大大提高代码保护的效率。然而在日常开发中因为短少对于 commit message 的束缚，导致填写内容随便、品质参差不齐，可读性低亦难以保护。在我的项目中引入 commit message 标准已是火烧眉毛。

用什么标准？

当初市面上比拟风行的计划是约定式提交标准（Conventional Commits），它受到了 Angular 提交准则的启发，并在很大水平上以其为根据。约定式提交标准是一种基于提交音讯的轻量级约定。它提供了一组用于创立清晰的提交历史的简略规定；这使得编写基于标准的自动化工具变得更容易。这个约定与 SemVer 相吻合，在提交信息中形容新个性、bug 修复和破坏性变更。它的 message 格局如下:

< 类型 >[可选的作用域]: < 形容 >

[可选的注释]

[可选的脚注]

Quick Start

1. 全局装置 commitizen & cz-conventional-changelog

commitizen 是一个撰写合格 commit message 的工具，用于代替 git commit 指令，而 cz-conventional-changelog 适配器提供 conventional-changelog 规范（约定式提交规范）。基于不同需要，也能够应用不同适配器。

npm install -g commitizen cz-conventional-changelog
echo '{"path":"cz-conventional-changelog"}' > ~/.czrc

装置结束后，可间接应用 git cz 来取代 git commit。

全局模式下，须要 ~/.czrc 配置文件, 为 commitizen 指定 Adapter。

2. 我的项目内装置 commitlint & husky

commitlint 负责用于对 commit message 进行格局校验，husky 负责提供更易用的 git hook。

Use npm
npm i -D husky @commitlint/config-conventional @commitlint/cli

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

commitlint 只能做格局标准，无奈涉及内容。对于内容品质的把控只能靠咱们本人。

3. 增加相应配置

创立 commitlint.config.js

# In the same path as package.json

echo 'module.exports = {extends: ["@commitlint/config-conventional"]};' > ./commitlint.config.js

引入 husky

# package.json

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

执行 git cz 进入 interactive 模式，依据提醒顺次填写 

1.Select the type of change that you're committing 抉择改变类型 (<type>)

2.What is the scope of this change (e.g. component or file name)? 填写改变范畴 (<scope>)

3.Write a short, imperative tense description of the change: 写一个精简的形容 (<subject>)

4.Provide a longer description of the change: (press enter to skip) 对于改变写一段长形容 (<body>)

5.Are there any breaking changes? (y/n) 是破坏性批改吗？默认 n (<footer>)

6.Does this change affect any openreve issues? (y/n) 改变修复了哪个问题？默认 n (<footer>)

生成的 commit message 格局如下：

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

填写结束后，husky 会调用 commitlint 对 message 进行格局校验，默认规定 type 及 subject 为必填项。

任何 git commit 指令的 option 都能用在 git cz 指令上, 例如 git cz -a

Commit message 标准在 rrd-fe 落地应用状况

针对团队目前应用的状况，咱们探讨后拟定了 commit message 每一部分的填写规定。

1. type

type 为必填项，用于指定 commit 的类型，约定了 feat、fix 两个次要 type，以及 docs、style、build、refactor、revert 五个非凡 type，其余 type 暂不应用。

# 次要 type
feat:     减少新性能
fix:      修复 bug

# 非凡 type
docs:     只改变了文档相干的内容
style:    不影响代码含意的改变，例如去掉空格、扭转缩进、增删分号
build:    结构工具的或者内部依赖的改变，例如 webpack，npm
refactor: 代码重构时应用
revert:   执行 git revert 打印的 message

# 暂不应用 type
test:     增加测试或者批改现有测试
perf:     进步性能的改变
ci:       与 CI（继续集成服务）无关的改变
chore:    不批改 src 或者 test 的其余批改，例如构建过程或辅助工具的变动

当一次改变包含次要 type 与非凡 type 时，对立采纳次要 type。

2. scope

scope 也为必填项，用于形容改变的范畴，格局为我的项目名 / 模块名，例如：node-pc/common rrd-h5/activity，而 we-sdk 不需指定模块名。如果一次 commit 批改多个模块，倡议拆分成屡次 commit，以便更好追踪和保护。

3. body

body 填写详细描述，次要形容改变之前的状况及批改动机，对于小的批改不作要求，然而重大需要、更新等必须增加 body 来作阐明。

4. break changes

break changes 指明是否产生了破坏性批改，波及 break changes 的改变必须指明该项，相似版本升级、接口参数缩小、接口删除、迁徙等。

5. affect issues

affect issues 指明是否影响了某个问题。例如咱们应用 jira 时，咱们在 commit message 中能够填写其影响的 JIRA_ID，若要开启该性能须要先买通 jira 与 gitlab。参考文档：docs.gitlab.com/ee/user/pro…

填写形式例如：

re #JIRA_ID
fix #JIRA_ID

示例

  • 残缺的 commit message 示例

  • 相应的 git log

如果你喜爱这篇文章，心愿能动动小手点个在看与转发反对一波。

人人贷大前端技术核心
juejin.im/post/5d0b3f8c6fb9a07ec07fc5d0

退出移动版