GitLab分支管理规范

GitLab 分支管理规范

本规范用于描述日常研发流程中关于 GitLab 上代码分支使用的规则, 大家共同严格遵守规范, 避免出现分支管理混乱现象, 保证日常的发版上线工作顺利进行。

• Workspace: 工作区, 平时我们写代码的地方
• Index: 暂存区, 写完代码后让它变成的待提交的状态
• Repository: 本地仓库, 提交暂存区的代码到这里, 记录进入代码本地管理
• Remote: 远程仓库, 将本地仓库的修改的代码提交到远程, 可以供远程协作的人下载

分支管理规范主要遵循 gitflow 的分支管理流程, 见下图:

分支介绍

master 分支

只存线上的代码, 只有确定可以上线时的才合并到 master 上, 并且在 master 的基础上打 Tag。

develop 分支

初次创建 develop 时, 需要从 master 分支拉取, 保持开发时代码和线上最新的代码相同。develop 分支是在开发时的最终分支, 具有所有当前版本需要上线的所有功能。

feature 分支

• 用于开发功能的分支, 必须从最新的 develop 分支代码拉取。分支命名基本上是 feature/xxxxx (和功能相关的名字)
• 不强制提交到远程仓库, 可以本地创建
• 比如, 我要开发登录功能, 我从 develop 分支的最新代码创建新分支命名为 feature/login, 然后切换到这个新分支开始开发, 开发完成后, 测试差不多完成, 合并到 develop 分支

release 分支

• 当 develop 分支已经有了本次上线的所有代码的时候, 并且以通过全部测试的时候, 可以从 develop 分支创建 release 分支了, release 分支是为发布新的产品版本而设计的
• 通过在 release 分支上进行这些工作可以让 develop 分支空闲出来以接受新的 feature 分支上的代码提交, 进入新的软件开发迭代周期
• 在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息(版本号、发布时间、编译时间等等)
• 比如, 此次 1.0 版本所有的功能版本都已经合并到了 develop 上, 并且所有测试都已经通过了测试, 那我就创建新的 release 分支 release/v1.0, 切换到新分支, 修改最新的版本号等, 不允许大的更改

hotfix 分支

• 当线上出现 bug 需要紧急修复时, 从当前 master 分支派生 hotfix 分支
• 修改线上 bug, 修改完成后合并回 develop 和 master 分钟
• 比如, 在线上 v1.0 登录功能出现问题, 我从 master 拉取代码创建新的分支 hotfix/v1.0_login, 修改完成后合并到 master 和 develop 上

业务需求流程

1. 当接收到正常的业务需求时, 需要约定一个大的发布版本(一次迭代)以及这个发布版本包含的多个 jira 任务, 一个发布版本必须在一个时间点上发布; 如果 jira 上的任务粒度太大, 则需要拆分细化成更小的 jira 子任务(工作量在 1~2 人日为准, 最好控制在一天以内)
2. 以 develop 为基准创建一个分支, 分支名称为 feature-jira编号-开发人员姓名全拼, 如 feature-ONC-21-lishaohua, jira 任务 ONC-21 的所有开发工作都在 feature-ONC-21-lishaohua 分支上进行, 所有开发过程的 commit message 需要填写具体的开发内容
3. 开发及单元测试工作完成后创建 merge request 合并到 develop 分支, 合并请求消息同样需要复制 jira 的内容描述以及具体的开发内容
4. 开发人员的自测工作基于合并后的 develop 分支代码进行, 如果这个发布版本所有 jira 任务全部自测通过后, 基于测试通过的 develop 分支创建一个 release 分支, 分支名称为 release-版本号, 如 release-ctrip1.0, 测试人员基于 release 分支进行测试
5. 测试人员继续在新建的 release 分支上进行回归测试和验证, 如果存在 bug 直接在该分支修改并合并到 develop 分支, 如果验证通过则准备生产上线
6. 生产上线时将 release 代码合并到 master 分支, 并打 tag, tag 名称为 tag-版本号, 从 master 打包上线

线上紧急 bug 修复流程

1. 当发现线上 bug 需要紧急修复时(开发人员需要确保 bug 修复已经在 jira 录入), 需要以 master 分支为基准创建一个 hotfix 分支, 分支名称为 hotfix-jira编号-开发人员姓名全拼
2. bug 修复代码直接在新建的 hotfix 分支上提交, commit message 需要填写具体的开发内容。测试人员直接在 hotfix 分支测试
3. 测试通过后, 开发人员同时请求合并到 master 分支和 develop 分支, 合并请求消息同样需要复制 jira 的任务描述以及具体的开发内容
4. 生产上线时将 hotfix 代码合并到 master 分支, 并打 tag, tag 名称为 tag-版本号-jira编号, 从 master 打包上线

高优先级开发任务流程

1. 如果在其他发布版本或迭代在开发中, 而优先级更高的迭代需要同时进行, 则需要特别注意。在创建 feature 分支时, 要确保 develop 分支和 master 分支时一致的没有被未上线甚至未测试的代码污染过的, 如果是则直接以 develop 分支为基准创建新的分支, 命名规范如同正常的业务需求流程; 如果 develop 分支上已经有其他未上线分支的代码且该分支代码上线优先级较低, 则不能以 develop 分支为基准创建分支, 需要以 master 分支为基准创建分支
2. 当更高优先级 feature 功能开发和自测完成后, 需要上测试环境, 这时, 需要以 master 分支为基准创建一个 release 分支, release 分支名称为 release-版本号, 所有较高优先级的 feature 分支合并到高优先级的 release 分支上, 并在该分支进行测试
3. release 分支测试通过后, 合并到 master 分支准备上生产, 同时 release 合并到 develop 分支; master 分支生产上线后打 tag, tag 名称为 tag-版本号

最后注意点

1. 长期的使用的分支有两个 master 分支和 develop 分支, 其他的辅助分支 hotfix 分支、feature 分支以及 release 分支都是临时分支, 其生命周期在合并到 develop 或 master 上之后就基本结束, 所以大家要养成良好的习惯, 在分支生命周期结束之后尽快删除掉, 以免堆积太多的分支而导致混乱
2. 大家开发过程中要勤提交、勤合并, 原则上一些方法级别、类级别或单元测试级别的修改可以发起一次提交, 提交的 commit message 写明工作的内容, 一个 feature 或 bug 的自测完成可以发起一次 merge request, merge request 的 message 内容要复制 jira 任务的描述以及具体的开发工作内容描述, 切勿堆积很大的工作量才发起合并