对版本管理规范进行大幅度修改，并增加换行

README.md

 # 项目规范和要求
 
-本文件用于规范所有项目成员的开发行为，并在一定程度上保障项目的代码质量。
-本文件规定了在项目开发中，代码应该怎么写，不能怎么写，以及部分规范在什么情况下可以例外。
-除了本文件中规定的所有规范以外，在部分项目中还有各自独立的规范要求和约定。在项目规范和本规范有冲突时，以具体项目规范为准。
+本文件用于规范所有项目成员的开发行为，并在一定程度上保障项目的代码质量。<br/>
+本文件规定了在项目开发中，代码应该怎么写，不能怎么写，以及部分规范在什么情况下可以例外。<br/>
+除了本文件中规定的所有规范以外，在部分项目中还有各自独立的规范要求和约定。在项目规范和本规范有冲突时，以具体项目规范为准。<br/>
 
 ## 基本目标
 
@@ -61,7 +61,7 @@ let tmp = null; //这是单行代码后的注释，通常用于变量说明和if
 **不要把注释写在一行代码的前面或者代码的中间**
 
 ### 2、必须添加的注释
-1. 除部分由其他脚本生成的脚本文件以外，在每个js文件的顶部必须有一个说明脚本功能的多行注释。多行注释至少需要说明清楚本脚本的大致功能和使用场合，并且要标注原始作者。
+1. 除部分由其他脚本生成的脚本文件以外，在每个js文件的顶部必须有一个说明脚本功能的多行注释。多行注释至少需要说明清楚本脚本的大致功能和使用场合，并且要标注原始作者。<br/>
   脚本功能注释例子如下：
 ```js
 /**
@@ -71,7 +71,7 @@ let tmp = null; //这是单行代码后的注释，通常用于变量说明和if
 ```
   在更旧的规范中，曾经要求在js文件顶部标注版本号。但是由于实际意义不大现在已经取消的这个要求
 
-2. 在每个函数之前，必须要有一个单行或者多行注释来说明函数的功能。如果函数比较复杂，则需要对参数和返回进行说明。
+2. 在每个函数之前，必须要有一个单行或者多行注释来说明函数的功能。如果函数比较复杂，则需要对参数和返回进行说明。<br/>
   函数注释例子如下：
 ```js
 //用gzip压缩目标对象或字符串
@@ -80,7 +80,7 @@ function zip(raw) {
 }
 ```
 
-3. 所有非函数内局部变量都必须在声明之后加上注释。只要一个声明在一个函数之外，或者在多个函数中使用，就必须加上注释。**但是当该变量是对其他脚本的引用的时候，可以不加注释**
+3. 所有非函数内局部变量都必须在声明之后加上注释。只要一个声明在一个函数之外，或者在多个函数中使用，就必须加上注释。**但是当该变量是对其他脚本的引用的时候，可以不加注释**<br/>
   例如：
 ```js
   const _ = require('lodash'); //这个变量因为是对其他库和脚本的引用，可以不加注释
@@ -95,7 +95,7 @@ function zip(raw) {
 1. 函数内声明的变量，使用次数比较多或者是变量名不够一目了然的，建议添加注释来对变量进行说明（*下例中的1类注释*）
 2. 接下来的数行代码用于实现一个明确功能的，建议添加注释对该段代码逻辑进行说明（*下例中的2类注释*）
 3. 代码中某个地方需要注意的时候，建议添加注释进行提醒（*下例中的3类注释*）
-4. 对于某些复杂的逻辑判断，其他开发人员可能不能一眼看懂的，建议添加注释进行说明（*下例中的4类注释*）
+4. 对于某些复杂的逻辑判断，其他开发人员可能不能一眼看懂的，建议添加注释进行说明（*下例中的4类注释*）<br/>
 应用示例：
 ```js
   // 获取用户数据
@@ -150,14 +150,14 @@ function zip(raw) {
 ## 代码规范
 
 ### 1、严格模式
-除由其他脚本生成的脚本，配置脚本和项目中固定的，不会频繁修改的文件以外，所有js脚本都**必须**使用严格模式编写。
+除由其他脚本生成的脚本，配置脚本和项目中固定的，不会频繁修改的文件以外，所有js脚本都**必须**使用严格模式编写。<br/>
 不要轻易使用公共变量。
 
 ### 2、代码的整合和分块
 1. 在代码中，应该适当的使用空行来对代码进行整合或者分块
 2. 对其他脚本的引用，应该一并放到文件头部统一声明
 3. 在多个函数内，或者在同一个函数内多处逻辑块内使用的变量，应该整合起来放在文件头部或者函数头部
-3. 在每一块连续的代码中，代码功能应当单一明确，不宜把不同的代码逻辑混在一起交替编写。具体来说，就是如果一段代码是负责完成某个功能的，那这段代码中就不应该出现任何和该功能无关的代码
+4. 在每一块连续的代码中，代码功能应当单一明确，不宜把不同的代码逻辑混在一起交替编写。具体来说，就是如果一段代码是负责完成某个功能的，那这段代码中就不应该出现任何和该功能无关的代码
 
 ```js
 // 这是一个比较好的代码整合分块例子
@@ -238,28 +238,28 @@ let var2 = '' //另一个在脚本中反复使用的变量
 * 对于作废的大段代码，要直接删除，不要使用注释的方式来将其保留起来
 
 ## 版本管理规范
-除了部分老旧项目以外，目前的新项目已经全部统一使用git进行版本管理。使用git时要遵循以下要求
+除了部分老旧项目以外，目前的新项目已经全部统一使用gitlab进行版本管理。使用git时要遵循以下要求
 
-### 1、在处理新需求之前，记得先拉取远程库的最新代码
-在每次开发之前拉取最新代码，可以尽可能的避免代码冲突。同时也可能会从别人的开发成果中获得一些现成的工具或者功能，以避免重复造车轮。
-### 2、仍在开发中的代码，可以本地提交，但是不要推送到远程库
-由于要尽可能的确保任意时候的远程库都能直接在线上运行，因此没有开发完整的功能要尽可能的避免推送到远程库。以降低线上故障的发生率。
-### 3、每次提交，必须要对本次的提交内容做出有意义的描述
+### 1、每次提交，必须要对本次的提交内容做出有意义的描述
 每一次提交，都必须要明确的说明这次提交了哪些修改，影响了什么功能。以下的提交说明是不可接受的
 * aaa *（如果确实什么都没有完成，可以这样写“XXX功能开发到途中，临时提交变更”）*
 * 提交 *（可以改成“提交了关于XXX功能的修改”）*
 * 改了几个bug *（可以改成“修改了XXX无法显示的bug和XXX数据错误的bug”，至少也是“修改了关于XX系统的三个bug”）*
 * 增加了一些功能 *（可以改成“增加了XX功能”或者是“增加了XX相关内容”）*
-### 4、提交不应太过频繁
-无论是本地提交还是远程推送，都不宜太过频繁。每个开发人员都应当在开发过程中明确自己工作的里程碑，然后在到达里程碑的时候再进行提交。如果过于以来提交和恢复功能，会影响到自身开发能力的提升。
-**但是ctrl+s需要经常按**
-### 3、在推送代码到远程库之前，必须要确保所有冲突已经解决，并且项目能够正确的运行，方可推送
+### 2、在推送代码到远程库之前，必须要确保所有冲突已经解决，并且项目能够正确的运行，方可推送
 始终要记住**远程库的代码就是线上要运行的代码**，因此，在确保冲突解决并且项目能正确运行之前，绝对不能把代码推送到远程库。
-**由于代码推送时没有处理代码冲突导致线上服务无法启动或者出现bug，直接扣绩效**
+**由于代码推送时没有处理代码冲突导致线上服务无法启动或者出现bug的，直接扣绩效**
+
+### 3、在处理一个需求或者对bug进行修改时，新建临时分支用于修改。不要在develop和master分支上直接进行开发
+在每次处理一个任务之前，一定要记得。首先从master或者develop分支上新建一个处理当前需求的临时分支，然后在这个分支上完成你的工作以后再将其合并到develop分支。并提交master分支的和并请求。
+### 4、已经完成任务的分支要记得删除，避免项目分支过多导致混乱
+由于要尽可能的确保任意时候的远程库都能直接在线上运行，因此没有开发完整的功能要尽可能的避免推送到远程库。以降低线上故障的发生率。
+### 5、为了确保每个项目成员能都能正确的使用分支，请先阅读以下链接的内容并照做
+[git分支练习用项目](http://114.55.97.172/chenhao/git-branch-test/tree/develop)
 
 ## 发布规范
 ### 1、测试站的发布流程
-在测试库进行测试的时候，不需要使用git进行提交。在没有代码冲突的前提下，完全可以直接使用FTP软件直接把修改过的文件直接托上去覆盖原本的文件进行测试。
+在测试库进行测试的时候，不需要使用git进行提交。在没有代码冲突的前提下，完全可以直接使用FTP软件直接把修改过的文件直接托上去覆盖原本的文件进行测试。<br/>
 为了避免git版本过于零碎，并不建议每次调试修改都提交一个版本然后用git拉去最新的到服务器上。
 
 ### 2、正式站的发布流程