前端开发流程规范

本规范处于试行阶段，欢迎提出 issue

本流程规范暂定下列三个规范，涵盖方方面面。如有异议，可以提出修改意见。集思广益，方得始终。

流程规范

流程规范主要指开发流程的规范，此规范需要配合前端、后端、设计、产品、测试、运维等必要环节，分为开发前规范和开发阶段规范两个部分。

开发前规范

开发前首先应当十分确定产品需求、服务人群、开发周期、开发模式等一系列要素，其中产品需求、服务人群应当由产品、运维等进行把控，新产品开发前必须进行产品研讨会，相关人员应当到场（前端、后端、设计、产品、测试、运维等必要环节相关人员），进行产品论证，论证通过则产品应当书写产品文档，包含设计文档，开发规划等相关信息，交由领导审核，通过进入下一步，不通过打回研讨，直至通过。

开发前流程走完之后，进入开发阶段规范

开发阶段规范

在正式产品设计文档、开发规划等文档确立下发后，所有负责产品（项目，后文用项目代替）的前端、后端开发人员，应当参加项目开发前会议。该会议主要探讨以下内容

项目技术选型
项目功能分块
功能结构任务划分
功能结构任务相应开发时间（此时间不包含测试时间，需要对应负责的前端、后端自行预估）
单元测试和联合测试

以上时间均不包含测试时间

以上流程走完，进入项目开发过程

代码规范

本规范主要在开发过程中，包含强制执行内容和非强制执行内容

强制内容

强制使用 eslint作为代码规范检查
强制使用 prettier作为代码格式化插件
强制使用yarn作为开发过程中架包管理工具
不得使用git命令行进行代码提交推送（回退，rebase等除外）
函数注释强制使用多行注释，并且遵守jsDoc规范

具体举例如下

/**
 * 防抖函数
 * @param {Function} method 事件触发的操作,fn
 * @param {Number} [delay = 500] - delay 多少毫秒内连续触发事件，不会执行
 * @returns {Function}
 */
export function __Debounce(method: Function, delay: number = 500): Function {
  let timer: number | null = null
  return function(this: any) {
    let self = this
    let args = arguments
    timer && clearTimeout(timer)
    timer = setTimeout(function() {
      method.apply(self, args)
    }, delay)
  }
}

非强制内容

推荐使用 soureTree 进行代码推送
推荐使用 vscode 作为开发工具
推荐使用 Typescript 作为开发语言（视团队具体情况）

详细代码规范细则见《代码规范细则》

提交规范

代码提交规范包含以下几个部分

commit 规范
合并代码规范
代码推送规范

commit 规范

commit 规范代表每次提交时的附带信息（Commit message）。主要包含以下三个部分

header
body
footer

其中，header 是必填的，Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）

type

用于说明 commit 的类别，只允许使用下面 7 个标识。

feat：新功能（feature）
fix：修补 bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改 bug 的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动

scope

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

例如在Vue中，影响视图层则标识符为 View，更新Vuex不影响视图则为 Controller，更新组件而不影响其他则为 Model 等等。

如果你的修改影响了不止一个scope，你可以使用*代替。

subject

subject 是 commit 目的的简短描述，不超过 50 个字符。

其他注意事项：

结尾不加句号

更具体的 commit 规范详情查看这篇文章

代码合并规范

代码合并规范又称为分支合并规范

为了得到清晰的分支历史，在进行分支合并的时候有两点规范需要注意：

所有分支的合并都采用非快进模式，必须再次创建一个提交（commit），以进行合并
所有非master分支只能通过定期同步master分支来获取最新代码，不得通过直接合并其他分支来实现代码同步

git 分支规范

名称	说明	命名规范	命名示例	合并目标	合并操作
master	主分支，线上稳定版本	master	master	–	–
release	待发布(通过稳定测试)分支，下个版本需上线的版本，发布之后及时删除即可	release/xxx	release/v1.0.0	master	merge request
develop	当前正在开发的分支，测试分支	develop	develop	master	merge request
feature	功能分支，每个功能需分别建立自己的子分支，开发完毕需要删除	feature/版本号-功能名	feature/v1.0.0-Login	develop	merge request
hotfix	紧急修复分支	hotfix/xxx	hotfix/v1.0.1	master/develop	merge request

git 流程图如下

git分支流程图

代码合并前尽量保证 commit 的整洁，如有条件可以使用 git rebase命令。