Merge branch 'wzw-master-patch-80157' into 'master'

git.md

+# gitlab 使用规范
+
+git 的本质是基于分支来管理代码。任何对master分支对修改都需要创建分支，
+然后通过提交pull request 都方式来合并代码。
+所以master分支对任何人不应该有写权限，包括管理员。
+总结来说，必须要遵循对原则是:
+
+```
+master 分支任何人都没有权限提交代码
+```
+
+```
+通过pr 提交代码，由管理员审核代码合并进入主干。
+```
+
+
+## 推荐开发流程
+
+适用情况
+
+```
+1. 没有多个版本一起开发都情况
+2. 多个版本一起开发，发布分支只有存在bug都情况，才会去修复
+3. 要有严格ci控制master分支的代码质量
+```
+
+开发者提交代码的流程:
+
+```
+1. 从最新的master分支创建新的branch
+2. 修改代码(大部分情况一次修改应该不超过200行代码，尽量小步快跑)
+3. 提交pr
+4. 跑ci(可以用我们的jenkins，后面会详细讨论要检查的内容)
+5. code review
+6. 管理员合并
+```
+
+发布版本的流程:
+
+```
+1. 从最新master分支建立tag（比如: 1.2.2）
+2. 开始更多的测试在 1.2.2
+3. 如果测试符合预期，那么1.2.2 就发布作为一个版本
+4. 如果测试出现bug。那么一般又回到 1
+```
+
+这样发布版本有一个前提，那就是测试基本上是自动化的，这个测试时间不会很长。
+并且master分支的代码质量控制的非常好，而这个就需要非常好的ci检查
+
+如果做不到这一点，可以建立一个 release 分支专门用于发布.
+(有些情况下：用master 分支 和 develop 分支。master分支就相当于我们的release， 而develop相当于我们的 master)
+
+流程是:
+
+```
+1. 同步最新的master分支到release
+2. 在release 分支上测试，并修复代码。很多时候，修复代码同时还要合并到master（工作量要大于我们上面的简单模式）
+3. release 分支测试稳定以后，发布tag
+4. 很多时候会建立很多relase分支，比如release1 表示 1.0.0 - 1.99.99 大版本的分支。
+   比如go语言的代码仓库有: release1 ～ release11 11个release 分支
+```
+
+关于ci要做事情:
+
+```
+1. 最基本的要求: build 能通过
+2. 单元测试覆盖率 30% 以上，并且全部通过
+3. 代码静态检查，规范检查，全部通过
+4. 集成测试全部通过（系统所有功能的一个测试集合）
+```
+
+如果你有什么好的想法，欢迎给我提交pr