主要规定一下关于开发过程中的分支管理
1、长期存在分支4个（代码合并顺序 a => b => c => d）
a)、develop分支：部署开发环境的分支。
b)、test分支：部署测试环境的分支。
c)、release分支：预发布环境分支。
d)、master分支：部署正式环境分支。
2、短期分支2个
feature：功能分支
a、开发新需求的时候，或者开发紧急需求时：
1).如果单人开发从当前master分支上，创建一个功能分支， 命名为feature/需求功能_姓名(可简写)_日期。
2).如果多人开发从当前master分支上,创建一个功能分支, 命名为feature/需求功能日期,个人从feature/需求功能 日期 分支切出自己的分支命名为feature/需求功能姓名 (可简写) 日期。
b、当需要进行在开发环境或者测试环境进行测试的时候，将 feature/xx_xx_xx功能分支merge到develop或者test分支上进 行发布版本测试。
c、开发过程需要测试，请把自己的 feature 合并 到develop分 支。发布develop分支。
bugfix：bug修复分支
a、如果线上出现bug，务必从当前master分支，创建一个分支， 名为bugfix_修复bug功能_姓名(可简写)_日期
b、代码写完后，请合并到develop、test、release等分支进行发 布测试，测试完成后再合并到master。
3、版本管理
有较大改动时上线时，要对master分支进行版本管理，采用tag标签的形式标注出上线日期及版本号。
注意：
分支命名尽量不要使用中文（某些特殊情况除外）。
不要在长期分支（develop,test,release,master）上直接开发代码。
不要反向，把develop或test的代码merge到自己的feature分支。
提交：提交代码一定要注明改动内容，内容较多的话，注明几项重大内容改动。
冲突：遇到冲突情况请联系下有关代码开发人员。其他相互调用特殊 情况也可以相互多沟通。
合并：feature分支、bugfix分支，上线前，请一定要合并到develop 分支、test分支，进行测试，测试完成后再合并到release分 支，master分支。
清理：功能上线稳定后，请开发人员各自清理remote端的 feature 分支、bugfix分支。
1、文件夹、组件命名规范，组件结构规范
a）文件夹：
文件夹名称应统一格式，小写开头，见名思意，page页面下 的文件夹名称统一以page结尾，例如：homePage,loginPage。 其余文件夹名称统一按照项目结构目录命名规范统一命名。
b）组件：
组件名以单词大写开头，当多个单词拼写成的组件时，采用驼 峰式命名规则。一般是多个单词全拼，减少简写的情况，这样 增加可读性。
组件应该都放到components文件夹下，单个页面独立一个文 件夹，用来放相对应的组件文件以及页面相关的样式文件，样 式少可直接写到页面组件里边，这样更符合组件化的思想。
页面级组件应该放到相对应页面文件夹下，比如一些组件 只 有这个页面用到，其他地方没有用到的，可以直接放到页面文 件夹，然后以父组件开头命名，例如： HomeHeader.vue,HomeNav.vue。
c）基础组件：
当项目中需要自定义比较多的基础组件的时候，比如一些 button，input，icon，建议以一个统一的单词Base开头，或者 放到base 文件夹统一管理，这样做的目的是为了方便查找。
项目级组件一般放到公共文件夹public或 src/components(当 前项目使用)下给所有的页面使用。
2、html Template模板文件
a）标签语义化，增加代码可读性。
b）样式class的命名：统一以小写字母开头，小写字母、下划 线和数字组成。命名中尽量避免使用中文拼音，应该采用 更简明有语义的英文单词进行组合。不建议使用驼峰法命 名class属 性。使用下划线的目的是为了和第三方库中的命 名冲突。例如：xx_left,xx_line。
c）多特性分行写，提高可读性。即一个标签内有多个属性， 属性分行写。
3、script js代码
a）应该遵守 JS 的规范和相关ES规范。
b）组件名称：以大写字母开头驼峰法命名。
c）不必要的调试信息 console.log，debugger使用完及时删除。
d) 全局指向问题，建议统一使用_this命名，增加代码可读性便于后期维护。
e) 常量名声明使用大写并单词间使用下划线分隔。
f) 私有变量声明使用下划线开头。
g) 尽量保持函数功能的单一性，低耦合性，不要过大。
4、注释
a) 函数声明注释：不必要在每一个函数都写注释，但是在公 共函数，还是建议补全注释，让后面的人不需要重复造轮子。
b) 复杂的业务逻辑、特殊情况的代码，对于特殊用途的变量、 使用了某种算法思路的代码要进行注释说明。
c) 注释需要标明作者、创建/修改时间、函数描述、功能等信 息。
5、style 样式代码
a) 尽量通过继承和层叠重用已有样式。
b) 兼容多个浏览器时，将标准属性写在底部。
c) 多选择器规则之间换行,增加可读性。
d) 避免使用行内样式。
6、不要轻易改动项目级CSS、JS、html、vue等文件。若改动后， 要进行全面测试。
7、所有变量、类名、函数命名尽量精确，语义化,不必担心长度问 题。