目录

一、代码托管

二、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 工作流程

 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并验证后

生产环境分支。

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

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

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

新功能开发分支。

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

预发布分支。

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

生产环境问题修复分支。

  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分支。
Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐