从0到1开发实战手机站（二）：Git提交规范配置

时间 2019-11-08

标签开发实战手机 git 提交规范配置栏目 Git 繁體版

原文原文链接

生活不能随意过，代码也不能随意写。vue

前一篇文章咱们已经把项目搭建好了，那是否是立刻就开始写页面了呀？ios

NO！git

不管在哪家公司，都会有相应的代码规范。新入职的员工每每第一步就要接受代码规范的学习。程序员

既然是实战项目，咱们也得在写页面以前把相关的规范配置作好。github

今天咱们先来看看项目中git的使用及相关规范吧。vue-cli

Git规范及项目配置

目的

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

版本规范

1.分支

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

2.Tag

采用三段式，v版本.里程碑.序号，如v1.2.3shell

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

3.changelog

版本正式发布后，须要生产changelog文档，便于后续问题追溯。npm

提交规范

Git commit日志基本规范

每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。json

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
复制代码

注意冒号后面有空格。bash

其中，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提交规范及如何配置，实在是小肆深知在实际工做过程当中遵照规范是多么重要的一件事.

尤为是团队开发或是开源项目，能够说一个程序员的代码素质从他的每一次提交记录就能体现一二，因此还望你们能重视起来。

接下来几篇小肆会为你们带来代码效验、自动格式化、手机端适配、判断访问客户端类型等前期准备工做，关注个人公众号"技术放肆聊"持续关注吧！