前言
什么是前端规范
前端规范是对前端开发行为的制定一系列标准、规则
规范的意义
- 提高开发效率、团队协作效率, 降低沟通成本
- 降低新成员融入团队的成本, 同时也一定程度避免挖坑
- 实现高度统一的代码风格，提高可读性，方便review, 另外一方面可以提高项目的可维护性
规范对象（过程规范）
- 开发流程规范
- 交互、设计规范
- 交互、设计与前端对接规
- 前端开发规范
- 后端接口与数据结构规范
- 前端与后端对接规范
- 前端行为规范
项目开发流程规范
UI设计规范
设计规范是什么？
能够对界面UI中的设计元素（如：Logo、配色、字体、排版等）和通用组件资源进行管理和归纳的规范性文档。
设计规范的作用是什么？
设计规范能够为团队解决诸多问题，大大提高团队协作效率，其作用主要体现在如下方面：
1. 解决团队协作项目控件使用混乱
一个包含几十页甚至几百页的大型项目，一般都是团队协作一起完成。若没有制定的设计规范，想保持不同页面同一控件的统一性，几乎是不可能的。但是，如果在多人进行协作某一项目前，UI设计师制定一份设计规范，其他协作成员都遵循此规范，就可以有效的把控视觉统一性了，提高工作效率也就变得轻松多了。
2. 保持产品迭代过程中品牌一致性
在产品的后期维护过程中，少不了迭代。若没有制定的设计规范，在经过多次迭代后，我们很可能忘记了设计初衷。版本3中的LOGO样式可能和版本1相差越来越远。若有了设计规范，在后期迭代过程中就很容易保持初衷，良好的维护品牌形象。
3. 大大提高开发人员工作效率，减少不必要的代码重复
有了设计规范，开发人员可快速调用一套代码，大大提高工作效率。
现有成熟的开源组件库
关于设计规范，极力推荐看看 Ant Design 的设计原则、设计价值观（自然、确定）和对于人机交互的理解
开发流程规范
Git Flow 规范
Git安装配置及基本使用
- 从官网下载安装包，手动完成安装。
- 打开Git Bash命令行工具，执行命令ssh-keygen -t rsa -C Email-Addresss生成一个密钥对。
- 登录到Git远程仓库，找到SSH Keys，点击Add SSH Key，填写Title栏，复制用户目录下.ssh/id_rsa.pub文件的内容到Key，点击Add Key。
- 点击New project，填写完成后点击Create project新建一个仓库，点击Activity，点击SSH后复制SSH边上栏里的地址。
- 打开Git Bash命令行工具，切换到一个合适的目录，使用命令git clone 刚才复制的URL克隆创建的仓库。
- 进入目录cd 仓库名，执行命令git config --global user.email your-email，
- git config --global user.name your-name，设置你的个人信息。 执行命令：
- git status，查看当前状态，发现有未跟踪文件
- git add .，当前目录所有文件添加到暂存区
- git diff，比较当前工作区和暂存区有何不同
- git status，查看当前状态，发现有文件未提交
- git commit -m "注释"，把暂存区内容提交到本地仓库
- git push -u origin master，把本地仓库的提交推送到远程仓库
- git log，查看提交日志
Git本地分支管理
分支的创建、合并、删除
- git branch，显示所有分支
- git branch -a，显示本地和远程所有分支
- git checkout -b b1，从当前分支创建一个叫b1的分支并切换到b1分支
- git checkout master，切换到master主分支
- git merge b1，把b1分支的代码合并到master上
- git branch -d b1，删除b1分支，不能在被删除分支上执行
Git Tag标签管理
标签的创建、删除
- git tag t1，从当前分支创建一个名为t1的标签
- git tag -d t1，删除名为t1的标签
命名规则
- 每次提交必须写明注释，如果是修复Bug，请加上Bug号
- 创建特性分支，名称要以feture/开头，加上特性名
- 创建发布分支，名称要以release/开头，加上预发布版本号
- 创建Bug修复分支，名称要以hotfix/开头，加上Bug号
- 创建标签，名称要以tag/开头，加上发布版本号
- 合并分支时必须使用--no-ff参数，以保留合并历史轨迹
分支模型
整体流程图:
主要分支（保护分支）
master 主分支，稳定代码，为生产环境做准备的
develop 开发分支，为开发服务
分支关系类似下图：
辅助分支
1.特性分支
从develop分支创建，用于特性开发，完成后要合并回develop分支(推荐到线上创建merge request合并)。 操作过程：
- git checkout -b feature/Feature-Name develop，从develop分支创建feature/Feature-Name特性分支
- git checkout develop，开发完成后，需要合并回develop分支，先切换到develop分支
- git merge --no-ff feature/Feature-Name，合并回develop分支，必须加--no-ff参数
- git branch -d feature/Feature-Name，删除特性分支
- git push origin develop，把合并后的develop分支推送到远程仓库 分支关系类似下图:
2.发布分支
从develop分支创建，用于预发布版本，允许小bug修复，完成后要合并回develop和master(推荐到线上创建merge request合并)。
操作过程：
- git checkou -b release/1.2 develop，创建一个发布分支
- git checkout master，切换到master分支，准备合并
- git merge --no-ff release/1.2，把release/1.2分支合并到master分支
- git tag 1.2，从master分支打一个标签
- git checkou develop，切换到develop分支，准备合并
- git merge --no-ff release/1.2，把release/1.2分支合并到develop分支
- git branch -d release/1.2，删除这个发布分支
3.修复分支
从master分支创建，用于生产环境上的Bug修复，完成后要合并回develop和master(推荐到线上创建merge request合并)。
操作过程：
- git checkout -b hotfix/1.2.1 master，从master分支创建一个Bug修复分支
- git checkout master，切换到master分支，准备合并
- git merge --no-ff hotfix/1.2.1，合并到master分支
- git tag 1.2.1，为master分支创建一个标签
- git checkout develop，切换到develop分支，准备合并
- git merge --no-ff hotfix/1.2.1，合并到develop分支
- git branch -d hotfix/1.2.1，删除hotfix/1.2.1分支 分支关系类似下图:
参考：
1、git - 官网
2、git - 简明指南
Git Rebase Flow
Git 基本流程步骤
一、要开发一个新的功能的时候，从 master 切一个分支出来
- // 1. 拉取最新代码
- git pull --rebase
- // 2. 起一个新的分支
- 功能分支:
- git checkout -b feat/xxxx
- 修复分支:
- git checkout -b fix/xxxx 开发完毕提merge request，如果merge request没有冲突，则到此为止，直接通知相应人员就好了，如果产生了冲突，请按照下面步骤操作
二、功能开发完毕，需要合并到 master。这时候要先 rebase 下最新的 master 分支，再合并
- // 1. 切换master分支
- git checkout master
- // 2. 拉取最新代码
- git pull --rebase
- // 3. 切换到自己的分支
- git checkout feat/xxx 以上步骤完成之后，请按照下面步骤操作
- // 1. 基于master做rebase
- git rebase master
- // 2. 这个时候会产生冲突，产生冲突时，手动解决冲突
- git add .
- // 3. 进入下一个冲突
- git rebase --continue
- // 4. 如果都解决完了
- git push --force-with-lease
- // 5. 大功告成，让mr负责人直接合并代码吧 rebase的一些其他命令
- // 如果不需要当前的log
- git rebase --skip
- // 如果需要终止当前rebase
- git rebase --abort
Git Commit 规范
Commit 规范格式
目前比较流行的Git Commit规范就是 Angular.js 项目所使用的规范： Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
1、Header
type:
- feat：新功能（feature）
- fix：修补bug
- docs：文档（documentation）
- style： 格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动
scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
例如在Angular，可以是$location, $browser, $compile, $rootScope, ngHref, ngClick, ngView等。
如果你的修改影响了不止一个scope，你可以使用*代替。
subject
subject是 commit 目的的简短描述，不超过50个字符。
其他注意事项：
- 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
- 第一个字母小写
- 结尾不加句号（.）
2、Body
Body 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。
- More detailed explanatory text, if necessary. Wrap it to
- about 72 characters or so.
- Further paragraphs come after blank lines.
- - Bullet points are okay, too
- - Use a hanging indent 注意点:
- 使用第一人称现在时，比如使用change而不是changed或changes。
- 永远别忘了第2行是空行
- 应该说明代码变动的动机，以及与以前行为的对比。
3、Footer
Footer 部分只用于以下两种情况：
不兼容变动
如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。
- BREAKING CHANGE: isolate scope bindings definition has changed.
To migrate the code follow the example below:Before:scope: {myAttr: 'attribute',}After:scope: {myAttr: '@',}The removed `inject` wasn't generaly useful for directives so there should be no code using it.
关闭 Issue
如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。
- Closes #234
Revert
还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。
- revert: feat(pencil): add 'graphiteWidth' option
- This reverts commit 667ecc1654a317a13331b17617d973392f415f02. Body部分的格式是固定的，必须写成
This reverts commit <hash>.，其中的hash是被撤销 commit 的 SHA 标识符。
如果当前 commit 与被撤销的 commit，在同一个发布（release）里面，那么它们都不会出现在 Change log 里面。如果两者在不同的发布，那么当前 commit，会出现在 Change log 的Reverts小标题下面。
举个例子
例如一个新功能，添加登陆模块 git commit 中的信息可以这样写：
feat(login): add login module
其中feat为提交类型type，login为域scope，“add login module”为 commit 目的的subject简短描述
Git Commit 辅助工具git cz
有热心的网友评论说可以git cz工具来实现标准化，我也研究试用了下，还不错。这里分享下我的试用过程：
git cz 使用方法
一、配置git cz
- 全局安装插件commitizen
- npm install -g commitizen
- 进入你想要使用git cz命令的git项目初始化工具（安装+配置）
- commitizen init cz-conventional-changelog --save --save-exact
- 现在就可以使用git cz代替git commit来生成专业的commit了（不过第一步还是要先git add）
二、使用git cz
只需按照提示一步一步来就OK了！
- git cz
- # 指定commit的类型
- ? Select the type of change that you're committing:
- # 用于描述改动的范围，格式为项目名/模块名
- ? What is the scope of this change (e.g. component or file name): (press enter t** **o skip)
- # 对改动进行简短的描述
- ? Write a short, imperative tense description of the change (max 83 chars): (11)
- # 对改动进行长的描述
- ? Provide a longer description of the change: (press enter to skip)
- # 是破坏性的改动吗
- ? Are there any breaking changes?
- # 影响了哪个issue吗，如果选是，接下来要输入issue号
- ? Does this change affect any open issues?
Commitlint + husky约束
1、安装commitlint
- # Install and configure if needed
- npm install --save-dev @commitlint/{cli,config-conventional}
- # 初始化配置文件
- echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js
2、安装husky v4
- # Install Husky v5
- npm install husky@4.3.8 --save-dev
- # or
- yarn add husky@4.3.8 --dev
3、package.json中添加钩子
- "husky": {
"hooks": {"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"}- }
4、提交命令测试
- git commit -m "foo: this will fail"
- husky > commit-msg (node v10.1.0)
- No staged files match any of provided globs.
- ⧗ input: foo: this will fail
- ✖ type must be one of [build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test] [type-enum]
- ✖ found 1 problems, 0 warnings
- ⓘ Get help: github.com/conventiona…
- husky > commit-msg hook failed (add --no-verify to bypass) 参考网站
CommitLint：commitlint.js.org/
版本规范
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改，
- 次版本号：当你做了向下兼容的功能性新增，
- 修订号：当你做了向下兼容的问题修正。
先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
参考：
1、语义化版本
