乐趣区

从0到1开发实战手机站(二):Git提交规范配置

生活不能随意过,代码也不能随意写。
前一篇文章我们已经把项目搭建好了,那是不是马上就开始写页面了呀?
NO!
无论在哪家公司,都会有相应的代码规范。新入职的员工往往第一步就要接受代码规范的学习。
既然是实战项目,我们也得在写页面之前把相关的规范配置做好。
今天我们先来看看项目中 git 的使用及相关规范吧。
Git 规范及项目配置
目的

统一团队 Git Commit 标准,便于后续代码 review、版本发布、自动化生成 change log;
可以提供更多更有效的历史信息,方便快速预览以及配合 cherry-pick 快速合并代码;
团队其他成员进行类 git blame 时可以快速明白代码用意;

版本规范
1. 分支

master: 主分支 (保护分支),不能直接在 master 上进行修改代码和提交;
develop: 测试分支,所以开发完成需要提交测试的功能合并到该分支;
feature-*: 新功能开发分支,根据不同需求创建独立的功能分支,开发完成后合并到 develop 分支;
hotfix-*: bug 修复分支,根据实际情况对已发布的版本进行漏洞修复;
release-*: 预发布分支。

2.Tag
采用三段式,v 版本. 里程碑. 序号,如 v1.2.3

架构升级或架构重大调整,修改第 1 位
新功能上线或者模块大的调整,修改第 2 位
bug 修复上线,修改第 3 位

3.changelog
版本正式发布后,需要生产 changelog 文档,便于后续问题追溯。
提交规范
Git commit 日志基本规范
每次提交,Commit message 都包括三个部分:Header,Body 和 Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
注意冒号后面有空格。
其中,Header 是必需的,Body 和 Footer 可以省略。
Header:
Header 部分只有一行,包括三个字段:type(必需)、scope(可选)和 subject(必需)。
type
代表某次提交的类型,比如是修复一个 bug 还是增加一个新的 feature。
所有的 type 类型如下:

feat:新增 feature
fix: 修复 bug
docs: 仅仅修改了文档,比如 README, CHANGELOG 等等
style: 仅仅修改了空格、格式缩进等等,不改变代码逻辑
refactor: 代码重构,没有加新功能或者修复 bug
perf: 优化相关,比如提升性能、体验
test: 测试用例,包括单元测试、集成测试等
revert: 回滚到上一个版本
build: 影响构建系统或外部依赖项的更改
ci: 主要目的是修改项目继续集成流程
chore: 不属于以上类型的其他类型

scope
scope 用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
subject
subject 是 commit 目的的简短描述,不超过 50 个字符。其他注意事项:

以动词开头,使用第一人称现在时,比如 change,而不是 changed 或 changes
第一个字母小写
结尾不加句号(.)

Body:
Body 部分是对本次 commit 的详细描述,可以分成多行。
需要描述的信息包括:

为什么这个变更是必须的? 它可能是用来修复一个 bug,增加一个 feature,提升性能、可靠性、稳定性等等
他如何解决这个问题? 具体描述解决问题的步骤
是否存在副作用、风险?

有两个注意点:

使用第一人称现在时,比如使用 change 而不是 changed 或 changes。
永远别忘了第 2 行是空行

Footer:
如果需要的话可以添加一个链接到 issue 地址或者其它文档,或者关闭某个 issue。
项目配置
既然规范已经有了,那我们就按照规范开始实战吧。
首先我们新建两个分支:
git branch develop
git branch feature-git 提交规范
然后我们切换到新建的功能分支:
git checkout feature-git 提交规范
接下来我们就来添加 git 提交信息效验的配置。
使用 commitizen 来执行规范
全局安装:
npm install -g commitizen
mac 下需在前面加 sudo
项目目录下执行:
commitizen init cz-conventional-changelog –save –save-exact
配好后,之后用到 git commit 命令时,改为使用 git cz。
这时,就会出现选项,用来生成符合格式的 Commit message。

好,我们把刚刚的改动提交一下吧。先把修改加入暂存
git add .
使用 git cz 代替 git commit
git cz
结果如下:
生成 Change log
因为我们的 commit 使用向导生成完全符合规范,所以发布新版本时,可以用脚本自动生成 Change log。
生成的文档包括以下三个部分:

New features
Bug fixes
Breaking changes.

每个部分都会罗列相关的 commit,并且有指向这些 commit 的链接。
当然,生成的文档允许手动修改,所以发布前,你还可以添加其他内容。conventional-changelog 就是生成 Change log 的工具.
运行下面的命令即可:
全局安装
npm install -g conventional-changelog-cli
项目目录运行
conventional-changelog -p angular -i CHANGELOG.md -s -r 0
这时你会发现项目目录里面多了 CHANGLOG.md 文件
我们可以把命令放在 script 里面:修改 package.json 文件,在 script 中添加:
“version”: “conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md”
我们做一次提交来试试看:
git add .
git commit -m “feat: 添加生成 changelog 功能 ”
然后运行:
npm run version
之后我们看到 CHANGELOG.md 文件有了我们的提交日志:
注意,我之前提交过一次,但是 type 使用的是 build,所以不会在日志中体现。
最后我们再把 CHANGELOG.md 的变化做一次提交:
git commit -m “docs: 添加 CHANGELOG.md 文件 ”
细心的朋友可能已经发现,这两次提交我并没有使用 git cz 而是为了方便直接使用了 git commit -m “” 这种形式,时刻记着提交信息规范的话使用这种方式也没问题,但是有时候难免失误,比如不小心把 feat 打成 feet,那如何防止失误呢?来看看吧。
使用 commitlint 效验提交信息
首先还是安装依赖:
npm install –save-dev @commitlint/{cli,config-conventional}
npm install –save-dev husky
@vue/cli-service 也会安装 yorkie, 但 yorkie fork 自 husky 且并不和之后的版本兼容。所以这里我还是安装了 husky
在根目录新建文件 commitlint.config.js

module.exports = {
extends: [“@commitlint/config-conventional”],
rules: {
“type-enum”: [
2,
“always”,
[“feat”, “fix”, “docs”, “style”, “refactor”, “test”, “chore”, “revert”]
],
“subject-full-stop”: [0, “never”],
“subject-case”: [0, “never”]
}
};
在 package.json 中添加 husky 配置
“husky”: {
“hooks”: {
“commit-msg”: “commitlint -e $HUSKY_GIT_PARAMS”
}
}
这样就配好了,现在我们来测试一下:
上图可以看到,当我 type 输错时会报错,这样我们就不怕不小心打错自己没注意到的情况啦。

修改之后成功提交。
合并提交
最后我们把我们今天的工作提交到 github 上吧
git checkout develop
git merge feature-git 代码提交信息审查
git checkout master
git merge develop
git push
小结
今天花了较大篇幅讲解如何为何配置 GIT 提交规范及如何配置,实在是小肆深知在实际工作过程中遵守规范是多么重要的一件事.
尤其是团队开发或是开源项目,可以说一个程序员的代码素质从他的每一次提交记录就能体现一二,所以还望大家能重视起来。
接下来几篇小肆会为大家带来代码效验、自动格式化、手机端适配、判断访问客户端类型等前期准备工作,关注我的公众号 ” 技术放肆聊 ” 持续关注吧!
本系列文章目录:

用 vue-cli3 从 0 到 1 做一个完整功能手机站(一)
从 0 到 1 开发实战手机站(二):Git 提交规范配置

退出移动版