【DevOps研发管理方案】三：代码管理-Toy模板网

这篇具有很好参考价值的文章主要介绍了【DevOps研发管理方案】三：代码管理。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

目录

一、代码托管

二、Git FLow 工作流程

三、分支管理

1. 基本要求

2. 版本号

3. 角色划分与权限

4. 分支说明

5. 分支创建规则

6. 分支回收规则

一、代码托管

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

二、Git FLow 工作流程

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

说明：

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

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

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. 角色划分与权限

用户有四种角色划分：

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

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

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

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

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

Private：只有组成员才能看到
Internal：只要登录的用户就能看到
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

生产环境分支。

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

develop

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

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

feature-*

新功能开发分支。

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

release-*

预发布分支。

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

hotfix-*

生产环境问题修复分支。

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

5. 分支创建规则

👉 新需求加入

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

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

👉 普通迭代

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

👉 修复测试环境 Bug

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

👉 修复预上线环境 Bug

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

👉 紧急修复正式环境 Bug

上线运行一段时候后出现了严重Bug，需要紧急修复的，步骤如下：文章来源地址https://www.toymoban.com/news/detail-433749.html

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