一、创建分叉(Fork)

分叉(Fork)是原始存储库的一个副本，作用是（可以在不影响原始项目的情况下进行更改）

项目分叉步骤：

1.1、点击Fork按钮进行分叉

1.2、选择组进行分叉

 1.3、没有可使用的组需要创建组

1.4、选择组进行分叉等待分叉完成 

二、分支(Branch)

2.1、分支命名标准

分支名称	分支取名	分支说明
主分支	master	正式稳定环境
发布分支	release	发布环境
开发分支	develop	测试与开发环境
功能分支	feat-xxx	新功能环境，xxx采用项目管理工具的功能工单号
Bug分支	hotfix-xxx	正式环境修复Bug，xxx采用项目管理工具的工单号
	fix-xxx	测试环境修复Bug,xxx采用项目管理工具的工单号

2.2、分支详解

1、master 主分支

    代码库有且仅有一个主分支。提供给用户应用的正式版本【任何时候在这个分支上拿到的都是最稳定的】；每次发布打上Tag标签，如：0.1，0.2 或 0.3。

2、develop 开发分支

    开发人员日常开发与功能测试分支【存储最新的开发版】。如果想正式对外公布，需在Master分支上，对Develop分支进行 “合并”（merge）操作。因为Gitlab中默认对Master设置了分支保护(这个设置允许取消,如果存在多人开发的我的项目,不建议取消)，所以，当须要合并到Master的时候须要在Gitlab里提交合并申请由项目管理员合并。

3、功能分支

    功能分支属于临时性分支，个别合并完就会删除。它是为了开发某种特定功能，从master分支下面分进去；开发实现后，再并入Develop分支。

功能分支的名字为：【feat-xxx（xxx为功能编号）】。

4、Bug 分支

    项目测试版与正式版本发布后，会存在Bug情况，这时候就需要创建Bug分支进行修复；由于Bug呈现的的环境不一样，可以定义不同的Bug分支：

①测试环境：从develop上新建分支为【fix-xxx（xxx为Bug编号）】；

②正式环境：从master上新建分支为h【hotfix-xxx（xxx为Bug编号）】；

可以在Bug修复后，将它合并进develop或master，而后被删除（xxx编号可以使用项目管理工具的bug工单号）。

2.3、创建分支

2.4、分支保护

 管理员登陆GitLab，然后打开需要进行分支保护的项目（这里以Test_RunCMD项目为例）给develop分支添加保护。

三、项目管理工具

我这边使用的是禅道：

禅道_国内开源免费的项目管理工具https://www.zentao.net/

四、项目提交和迭代规范

4.1、提交规范

    每次提交代码内容，都需要编写【提交说明】（即：此次提交的类型是什么，新增或修改了哪些东西）【提交说明的格式为：（类型+主题）】

1、提交类型

        ①新功能：

        ②修复：

        ③重构：

        ④测试：

2、提交主题

将此次新增或修改的功能内容做一个简要说明，控制在60字以内，结尾不用加句号。

3、提交说明的格式示例

        新功能：增改菜单、增改权限

        修复：添加菜单出错，修改权限异常

        重构：加载菜单逻辑

        测试：增改菜单、增改权限

4、提交分支规范

    1.禁止向主分支间接提交代码，包扩代码仓库在线编辑批改。非凡状况（如版本号变更、CI变更）除外；

    2.禁止提交测试性代码到任何主分支源码（src）目录，测试代码只能存在于测试（test）目录；

    3.禁止任何工作分支跨主分支提交代码，工作分支从只能合并到与工作分支同源的主分支；

    4.禁止在开发过程批改主分支版本号；

    5.必须在代码提交到主分支前删除未应用的import语句和格式化代码。

    6.必须备注每一次提交，代码备注必须简要可读。精确的形容具备可检索性；

    7.必须备注每一次合并申请，对合并申请蕴含的性能点简要形容。精确的形容具备可检索性。

4.2、迭代开发流程标准

1. 总体组每周四制订下一迭代版本上线打算并确定迭代开发主分支版本号告诉到各核心（组）；
2. 各核心（组）责任人认领确认工作（截止周五），合成工作并下发开发人员，开发在新版本分支上开发；
3. 各核心（组）在周四前实现根本工作提交到迭代版本主分支交由测试组集成验证；
4. 测试组在集成测试分支打包测试，bug提交到禅道治理，相干责任人及时认领并修复，同时告诉测试组回归测试；
5. 上线值日人需在每周四上班前确定最终我的项目版本并归档输入；
6. 各核心（组）责任人提交最终《数据库变更脚本》、《环境变更脚本》告诉到上线值日人；
7. 各核心（组）责任人提交《程序变更阐明》、《上线验证性能列表》到测试组；
8. 上线值日人须要负责生产环境war包公布和数据库变更；
9. 测试组根据《上线验证性能列表》验证生产零碎公布正确性；
10. 测试组验证无误根据《程序变更阐明》公布上线变更告诉。测试不通过告诉上线值日人回滚本次公布程序和数据库及环境变更；
11. 总体组确定延期公布打算；
12. 延期上线流程参照第五条至第十条执行；
13. 其余工夫未经批准禁止公布程序和变更数据库操作

五、Bug修复流程

5.1、线上Bug修复流程

1. 以线上版本master主分支为源创立hotfix-xxx的修复分支；
2. 在hotfix-xxx的修复分支进行集成环境bug修复并向线上版本主分支提交合并申请；
3. 核心（组）责任人负责代码审核，批准或者回绝本次合并申请；
4. 测试组依据最新代码在集成测试环境进行补丁修复验证；
5. 验证无误后将本次合并申请同时cherry-pick到集成迭代开发主分支；
6. 公布流程参照【迭代开发流程标准的第五条至第十条执行】；

5.2、测试Bug修复流程

1. 以集成测试主分支为源创立fix-xxx的修复分支；
2. 在fix-xxx的修复分支进行集成环境Bug修复并向集成测试主分支提交合并申请；
3. 核心（组）责任人负责代码审核，批准或者回绝本次合并申请；
4. 测试组依据最新代码在集成测试环境进行补丁修复验证；
5. 验证无误后将本次合并申请cherry-pick到迭代开发主分支；
6. 公布流程参照【迭代开发流程标准的第五条至第十条执行】；