生涯不能随便过，代码也不能随便写。
前一篇文章我们已把项目搭建好了，那是不是立时就最先写页面了呀？
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 developgit branch feature-git提交范例然后我们切换到新建的功用分支:
git checkout feature-git提交范例接下来我们就来增加git提交信息效验的设置。
运用commitizen来实行范例
- 全局装置:
npm install -g commitizenmac下需在前面加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提交范例及怎样设置，实在是小肆深知在实际事情过程当中恪守范例是何等主要的一件事.
尤其是团队开辟或是开源项目，能够说一个程序员的代码素养从他的每一次提交纪录就可以表现一二，所以还望人人能注重起来。
接下来几篇小肆会为人人带来代码效验、自动花样化、手机端适配、推断接见客户端范例等前期准备事情，关注我的民众号”手艺豪恣聊”延续关注吧！
