APP代码管理与升级发布规范

一、代码书写规范

命名

文件/文件夹命名

文件夹/文件的命名统一用小写 或驼峰；
项目名称一律小写或带_ 下划线 连接；

js变量

?变量 ——命名方式：小驼峰 ； 命名规范：前缀名词；
?常量 —— 命名方式： 使用大写字母和下划线来组合命名；
?函数 —— 命名方式：小驼峰 ；命名规范：前缀动词；
?类、构造函数 —— 命名方式：大驼峰式命名法，首字母大写；
?Main.js文件中的全局变量在命名时需要规范“$变量名“；
取名须要闻名达意。比如：requestNewsData(); 如果命名的确不能明确表达代码含义，须要有注释说明。

Css变量

除nvue文件外建议使用scss编写语法。
css（class、id）命名规则
.block{} // 代表了最高级别的组件。
.block__element{} // 代表 block 的后代。
.block–modifier{} // 代表 block 的不同状态或不同版本。

注释说明

1.单行注释 —— // 说明。 尽量在代码行位进行书写
多行注释 ——
/*

• xxxx 描述较多的时候可以使用多行注释
• xxxx
  */

组件

每个 Vue 组件的代码建议不要超出 300 行 （建议父子组件组合或抽离成公共组件）。
Css及js建议随组件迁移，不建议加入公共样式文件。
全局组件在注册时建议抽离到单独的组件注册文件中。
公共组件文件建议存储到统一文件夹中。

代码书写风格

属性编写顺序

（一般遵循显示属性 -> 自身属性 -> 文本属性 -> 其他属性的书写格式）。
?显示属性：display/list-style/position/float/clear…
?自身属性（盒模型）：width/height/margin/padding/border
?背景：background
?行高：line-height
?文本属性：color/font/text-decoration/text-align/text-indent/vertical-align/white-space/content…
?其他：cursor/z-index/zoom/overflow…

代码性能优化

?合并margin、padding、border的-top/-right/-bottom/-left的设置，尽量使用短名称。
?选择器应该在满足功能的基础上尽量简短，减少选择器嵌套，查询消耗。但是一定要避免覆盖全局样式设置。
?禁止在css中使用*选择符。
?0后面不需要单位，比如0px可以省略成0，0.8px可以省略成.8px。
?如果可以颜色尽量用三位字符表示，比如#ccc。
?如果没有边框时，不要写成border:0;应该写成border:none。
?在保存代码解耦的前提下，尽量合并重复的样式。
?background、font等可以缩写的属性，尽量使用缩写形式。
?能以背景形式呈现的图片，尽量都写入CSS样式中。

代码规范工具

推荐使用ESLint，htmlButify等代码格式规范工具，来美化规范代码。

codeReview

所有影响到以往流程的功能需求更改发版前都需要codeReview ；
对于自己不熟悉的页面进行修改时，须于原开发人员沟通清楚业务逻辑，并提给测试人员进行全页面测试。

其他

VUE代码书写规范：https://github.com/pablohpsilva/vuejs-component-style-guide/blob/master/README-CN.md
eslint源码：https://github.com/eslint/eslint
JavaScript Standard规范 ：https://github.com/standard/standard

二、代码管理规范

分支规范

• master 主分支
• dev 主开发分支
• hotfix 修复bug分支
• feature 功能开发分支

主分支master

master分支永远受保护。不可在master分支上开发，进行commit，push操作。
master分支只接收merge操作。
每次发布正式上线的稳定版本（发布后第一天），将当前发布版本merge到master分支。
master分支的代码永远和线上代码保持同步。

主开发分支dev

dev分支为主开发分支。可以进行commit，push，merge操作。
一般不在dev分支上进行新功能的开发。dev分支用来做不同分支的代码整合。
每次master发布以后，需要把master的代码merge到dev上。保持master的代码同步。

hotfix分支 hotfix/xxxx

hotfix分支是由master分支checkout出来，用于热修复线上bug用。可以进行commit，push，merge操作。
修复完毕经验证后直接发布。发布完成后merge到master分支。

功能开发分支 feature/xxxx

用来进行新功能开发的分支。此分支由dev分支checkout出来，可以进行commit，push，merge操作。
按照功能或者版本可以同时checkout多个feature分支并行开发。开发完毕统一merge回dev。

工作流程

新功能开发

从dev分支checkout开发分支，如feature/new。
开发完成后提交测试。测试通过后由发布负责人修改package.json上的版本 ，填写版本更新内容。
正式发布完成后，由发布负责人把发布的版本merge到master分支。
最后把master分支merge到dev分支。

hotfix热修复

从master分支checkout热修复分支，如hotfix/newbug。
修复完成后提交测试。测试通过后由发布负责人修改package.json上的版本 ，填写版本更新内容。
正式发布完成后，由发布负责人把hotfix的merge到master分支。
最后把master分支merge到dev分支。

并行开发

从dev分支checkout多个并行开发的分支，如feature/new1,feature/new2,feature/new3…。
开发完成后由发布负责人将并行开发的分支统计后统一合并到dev或者一个新的feature分支上。（主要看短期内是否有多次发布排期）
提交测试。测试通过后由发布负责人修改package.json上的版本 ，填写changelog。
正式发布完成后，由发布负责人把发布的版本merge到master分支。
最后把master分支merge到dev分支。
鉴于项目大小，开发资源及人员等条件限制，在开发阶段可灵活调整工作流程。如
功能模块由单人负责时，由dev分支checkout出一个feature新功能分支，开发结束提测后会有禅道回馈bug。为了便于开发，此时可以fetch获取dev最新代码到本地feature分支直接修改bug，并提交合并。

注意点

只要发布到正式环境，不管改动多少，每次都必须版本 变动，同时changelog留下记录。
每次发布到正式环境后一定要记得同步代码回dev。
除了master，dev这两个分支类型外的所有分支都是临时分支。可以适当保留1-2个版本的分支后删除其他分支。
git reset –hard xxxx命令慎用，会引起代码无法恢复的可能。使用前务必commit本地库。
养成良好的习惯，每次开发前，提交代码前先同步代码。
为了便于理解可浏览下方流程图。

GIT Commit message 的格式

每次提交，Commit message 都包括三个部分：header，body 和 footer。
其中，header 是必需的，body 和 footer 可以省略。
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。

Header

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
type
用于说明 commit 的类别，只允许使用下面7个标识。
?feat：新功能（feature）
?fix：修补bug
?docs：文档（documentation）
?style： 格式（不影响代码运行的变动）
?refactor：重构（即不是新增功能，也不是修改bug的代码变动）
?test：增加测试
?chore：构建过程或辅助工具的变动
如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。
scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
如果你的修改影响了不止一个scope，你可以使用*代替。
subject
subject是 commit 目的的简短描述，不超过50个字符。

其他注意事项：

?以动词开头，使用第一人称现在时，比如change，而不是changed或changes
?第一个字母小写
?结尾不加句 （.）
?便于理解考虑，可以使用中文，规则和英文一样
Body，footer这里用到的情况较少，这里不做阐述。

分支与版本发布规范

基本原则：master为保护分支，不直接在master上进行代码修改和提交。
开发日常需求或者项目时，从master分支上checkout一个feature分支进行开发或者bugfix分支进行bug修复，功能测试完毕并且项目发布上线后，将feature分支合并到主干master，并且打Tag发布，最后删除开发分支。分支命名规范：
?分支版本命名规则：分支类型 _ 分支发布时间 _ 分支功能。比如：feat_20200902_electronic_commerce
?分支类型包括：feat、 fix、refactor三种类型，即新功能开发、bug修复和代码重构
?时间使用年月日进行命名，不足2位补0
?分支功能命名使用snake case命名法，即下划线命名。
Tag包括3位版本，前缀使用v。比如v1.2.31。Tag命名规范：
在名称后加alpha：测试版，加belta：正式发布版，再加入对应版本更新的次数。
比如：
?v2.0.0-alpha.1
?v2.0.0-belta.1
版本正式发布前需要生成changelog文档，然后再发布上线。

冲突解决方案

当提交最新文件时发现不可push时，需要拉去（git fetch origin hotfix/feature:tmp）最新代码，tmp为临时库，用于gitdifftmp比较新拉的代码和本地的代码区别。Gitmergetmp合并临时库到本地库。处理冲突（可能无冲突，仅是拉去最新代码），重新 add/commit/push行为。
最后需要将tmp临时库删除。
注意：观察“Auto merge ”过程中自动合并的文件，这样的文件中都会有需要手动合并的内容，不可以通过程序正常运行来作为没有需要手动合并内容的依据。

GIT的相关知识点提炼

GIT的常用操作
操作 描述 说明
git pull 拉取并合并代码 由于会自动执行merge，很容易导致冲突了也没注意到，不推荐
git fetch origin xxx:tmp 拉取远端代码但不合并
Tmp为在本地创建临时库，
用于diff比较代码差别 fetch，diff和merge的语法糖
推荐
git merge origin/xxx 合并代码到当前分支 推荐
git status -s 查看有变动的文件列表
git branch 查看所有本地分支
git branch -a 查看本地和远程分支
git branch -d xxx 删除本地xxx分支 必须不在xxx分支上才能删除
git checkout xxx 切换到xxx分支上 xxx分支必须存在
git checkout -b xxx 新建xxx本地分支并切换到xxx分支上 xxx分支必须不存在
git add . 提交所有本地工作区的改动到本地暂存区
git commit -m ‘注释’ 提交本地暂存区到对应本地分支上
git push 将本地分支上的代码推送到远端分支上
git log 查看当前分支上的commit记录
git reset –hard xxxx 回复本地版本到xxxx（git log查到的commit记录hash ）

三、APP升级发布规范

注意