gitlab设置统一提交格式 gitlab代码提交规范

转载

落花有意飞花 2024-02-22 17:12:34

GitLab 分支管理规范

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

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

gitlab设置统一提交格式 gitlab代码提交规范_git

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

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

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

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

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

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

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

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

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