【DevOps研发管理方案】三：代码管理

目录

一、代码托管

二、Git FLow 工作流程

三、 分支管理

1. 基本要求

2. 版本号

3. 角色划分与权限

4. 分支说明

5. 分支创建规则

6. 分支回收规则

---

一、代码托管

使用Git/SVN等开源版本控制系统进行代码托管。

二、Git FLow 工作流程

推荐使用Git Flow的模式进行代码分支管理。在使用Git Flow工作流程管理代码时，必须按照以下步骤执行。

说明：

1. 由开发管理员负责在统一代码仓库里创建空白的仓库，并clone到本地，初始化仓库，并push到远端。
2. 在统一代码仓库上设置保护分支，把master、develop分支保护起来，只有开发管理员可push。
3. 功能开发者clone代码到本地，然后初始化仓库。
4. 然后再开始新建功能分支，进行开发工作。
5. 新功能开发全部完成或部分完成后，功能开发者把最新代码push到远端同样的新功能分支里，并在统一代码仓库发起Merge request给开发管理员。
6. 开发管理员review代码，选择合并代码到develop分支，并可选择删除已经合并的新功能分支。
7. 当开发管理员处理完合并请求后，功能开发者切换到develop分支，直接删除自己的本地分支及远程分支，不要点击完成（Finish Feature），此时开发者pull远端develop分支最新代码即可，可忽视本地的push提醒。
8. release、hotfix分支和feature分支操作类似。
9. 不可点击完成新功能、完成发布版本、完成修复补丁，因为这样会导致自动合并代码到master或develop分支。

 Git Flow 工作流程

三、 分支管理

1. 基本要求

【强制】每一次commit必须有注释，注释内容遵循注释规范。

【建议】任务拆分时，建议合理控制任务粒度，一个新功能任务可一人独立完成，即一个feature新功能分支一人独立完成。

【建议】一次commit只做一件事情，便于后期版本回滚。

【强制】正确为每个项目设置Git提交用到的user.name和user.email信息，以公司邮箱为准，不可随意设置以影响无法正确识别。

【强制】每一个项目根目录下都必须提供readme.md文件，用来说明当前项目的主要功能。

2. 版本号

【强制】版本号（tag）命名规则：主版本号.次版本号.修订号，如2.1.13。

• 主版本号：当API兼容性变化时，主版本号需要递增；
• 次版本号：当增加功能，但不影响兼容性，次版本号需要递增；
• 修订号：当修复bug但不影响兼容性，修订号需要递增；

【强制】版本号仅标记于master分支，用于标识某个可发布/回滚的版本代码。

【强制】对master标记tag意味着该tag能发布到生产环境。

【强制】对master分支代码的每一次更新（合并）必须标记版本号。

【强制】仅管理员对master进行合并和标记版本号。

3. 角色划分与权限

用户有四种角色划分：

1. 功能开发者：模块中功能的开发人员，拥有浏览、push非主分支、提交Merge request的权限；
2. 开发管理员：由项目模块开发的小组长（team leader）担当，拥有管理git项目、合并分支和代码的权限，可以进行代码审查；
3. 发布管理员：由生产环境发布团队指定人员担当，拥有建立和管理Git项目、合并分支和代码、给master打tag版本号等权限；
4. 测试管理员：由测试团队指定人员担当。

【强制】用户有五种角色权限：Guest、Reporter、Developer、Maintainer、Owner

1. Guest：可以创建issue、发表评论，不能读写版本库；
2. Reporter：可以克隆代码，不能提交，【测试管理员】赋予该权限；
3. Developer：可以克隆代码、开发、提交、push，【功能开发者】赋予该权限；
4. Maintainer：可以创建项目、添加tag、保护分支、添加项目成员、编辑项目，【开发管理员】、【发布管理员】赋予该权限；
5. Owner：可以设置项目访问权限 - Visibility Level、删除项目、迁移项目、管理组成员。

注：开发管理员和发布管理员角色相同，但操作的项目范围不同。发布管理员可操作当前项目组下的所有项目。

组和项目有三种访问权限：Private、Internal、Public

1. Private：只有组成员才能看到
2. Internal：只要登录的用户就能看到
3. Public：所有人都能看到

4. 分支说明

每个Git项目固定含有master、develop、feature、release、hotfix分支类型。主分支master和develop是保护分支，只能进行合并请求，均不可直接提交代码。

功能需求或常规Bug修复，从develop拉取feature分支；线上紧急问题修复，从master拉取hotfix分支。

名称	master	release	develop	feature	hotfix
说明	线上稳定版本	待发布分支	当前正在开发的分支	功能分支，每个功能需分别建立自己的子分支	紧急修复分支
命名规范	master	release-xxx	develop	feature-功能名-版本号	hotfix-功能名-版本号
分支命名	master	release-v1.0.0	develop	feature-login-v1.0.0	hotfix-fixorderdetail-v1.0.1
pom文件版本定义	xxx-1.0.0-RELEASE	xxx-1.0.0-RELEASE	xxx-1.0.*-SNAPSHOT	xxx-1.0.*-SNAPSHOT	xxx-1.0.0-RELEASE
合并目标	-	master/develop	master	develop	master/develop
合并操作	-	merge request	merge request	merge request	merge request
创建人	发布管理员	发布管理员	开发管理员	开发者	开发者
生命周期	全过程	版本发布后	全过程	功能开发完成后	紧急修复bug并验证后

• master

生产环境分支。

1. 操作权限：仅管理员。
2. 合并说明：-
3. 推送说明：-

• develop

主开发分支，此分支包含：正在测试、等待测试的代码，属于不稳定代码分支。

1. 操作权限：仅管理员。
2. 合并说明：-
3. 推送说明：-

• feature-*

新功能开发分支。

1. 操作权限：仅允许对应开发人员操作。
2. 创建说明：创建自develop。
3. 合并说明：合并到develop：新功能开发完成，等待测试。

• release-*

预发布分支。

1. 操作权限：仅允许对应开发人员操作。
2. 创建说明：创建自develop。
3. 合并说明：
   • 合并到develop：预发布环境测试通过，修复代码回归。
   • 合并到master：预发布环境测试通过，发布。

• hotfix-*

生产环境问题修复分支。

1. 操作权限：仅允许对应开发人员。
2. 创建说明：创建自master。
3. 合并说明：
   • 合并到develop：问题修复完成并测试通过，修复代码回归。
   • 合并到master：问题修复完成并测试通过，发布。 

5. 分支创建规则

👉 新需求加入

如有一个订单管理的新需求需要开发，首先要创建一个 feature-[新功能] 分支，步骤如下：

1. 基于 develop 创建新的本地分支 feature-[新功能]。
2. 本地开发、测试。
3. 需求在 feature-[新功能] 分支开发完毕，准备提测时，要先发送代码合并请求，经开发管理人员代码审核通过后，将代码合并到 develop 分支，等待测试人员测试，并删除该远程分支。
4. 测试人员在 develop测试，不通过则回到第1步；测试通过后，研发人员再将代码发布到 release 供测试人员测试。
5. 测试人员在 release 测试，不通过则回到第1步；测试通过后，研发人员再将代码发布到 master 和 develop 分支。
6. 最后，待本次迭代内的所有特性均完成了测试，那么在 master 上打TAG标记版本号，准备发布新版本。

👉 普通迭代

若有一个订单管理的迭代需求，如果开发工时<1d，直接在 develop 开发，如果开发工时>1d，那就需要创建分支，在分支上开发。开发后的提测上线流程与新需求加入的流程一致。

👉 修复测试环境 Bug

在develop测试出现了Bug，需要新建分支进行修复。修复后的提测上线流程与新需求加入的流程一致。

👉 修复预上线环境 Bug

在 release 测试出现了Bug，则直接由开发者在release分支修复并提交。当测试完成之后，合并 release 分支到 master 和 develop 分支，此时 master 为最新代码，用于上线发布。

👉 紧急修复正式环境 Bug

上线运行一段时候后出现了严重Bug，需要紧急修复的，步骤如下：

1. 基于线上版本的TAG创建新的分支hotfix-[BUG]。
2. 本地开发、测试。
3. 修复完毕，推到远程分支。
4. 将该远程分支发布到测试环境。
5. 测试不通过，则回到第2步；测试通过，则将 hotfix-[BUG] 代码合并到master 和develop 分支，同时删掉 hotfix-[BUG] 分支，打TAG，准备发布补丁版本。

6. 分支回收规则

• master分支：长期存在。
• develop分支：产生于master分支,并长期存在。
• feature分支合： 合并回develop分支，经测试通过后，删除feature分支，或者feature分支与前期需求不符，直接舍弃。
• release分支：在release分支上进行充分测试，并修复Bug，合并回develop分支和master分支后，然后删除release分支。
• hotfix分支： 紧急Bug修复完成后，合并回maste分支，测试验证通过，再合并到develop分支，然后删除hotfix分支。