GitLib版本分支管理规范
2022-03-07 11:34:49 1 举报AI智能生成
GitLib版本分支管理规范
作者其他创作
大纲/内容
分支管理
master分支
分支说明
只存产品已经上线的代码，只有确定可以上线时的才合并到master上，并且在master的基础上打Tag。
适用角色
管理人员
触发条件
初始版本
代码上线
管理示例
例如：由管理人员统一管理，基于develop分支将基础产品所有已上线的功能合并到master分支，只有管理人员有操作master分支的权限，其他任何人员不能 pull/push master分支
develop分支
分支说明
初次创建develop时，要从master分支拉取，保持开发时代码和线上最新的代码相同。develop分支是在开发时的最终分支，具有所有当前版本需要上线的所有功能。
适用角色
管理人员
开发人员
触发条件
新的开发版本需求
管理示例
例如：当有新的需求版本时，由管理人员基于master分支创建develop分支，并未开发人员分配开发权限
feature分支
分支说明
用于开发功能的分支，从最新的develop分支代码拉取。分支命名基本上是feature/xxxxx（和功能相关的名字），不强制提交到远程仓库，可以本地创建
适用角色
开发人员
触发条件
新的功能模块
此分支不强制要求，能保证自己的develop分支不冲突即可
管理示例
例如：要开发登录功能，可以从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上。
正常开发流程
管理人员：有新需求，创建master分支，上传基础代码，已有产品需求，以当前产品上线功能作为master分支
管理人员：当接收到正常的业务需求时，约定一个大的发布版本，由管理人员在master分支基础上创建develop分支
开发人员：以develop分支为基础，创建一个功能模块开发分支，分支名称为“feature-功能编号-开发人员姓名简拼“，例如feature-cloud-21-wangrz”。所有开发过程的commit message需要填写具体的开发内容。
开发人员：开发及单元测试工作完成后创建merge request合并到develop分支，合并请求消息同样需要复制提交的内容描述以及具体的开发内容。
开发人员：单元工作基于合并后的develop分支代码进行，如果这个发布版本所有任务全部自测通过后
管理人员：基于测试通过的develop分支创建一个release分支，分支名称为“release-版本号”，如“release-orilogV1.0”，测试人员基于release分支进行测试。
测试人员：继续在新建的release分支上进行回归测试和验证，如果存在bug直接在该分支修改并合并到develop分支；如果验证通过则准备生产上线，
管理人员：生产上线时将release代码合并到master分支，并打tag，tag名称为“tag-版本号”，从master打包上线
紧急开发流程
管理人员：当发现线上bug需要紧急修复时，需要以master分支为基准创建一个hotfix分支，并为分支创建相应开发人员权限
开发人员：拉取分支，bug修复代码直接在新建的hotfix分支上提交，commit message需要填写具体的开发内容。测试人员直接在hotfix分支测试
测试人员：测试人员直接在hotfix分支测试
开发人员：测试通过后，开发人员同时请求合并到master分支和develop分支，合并请求消息需要复制任务描述以及具体的开发内容
管理人员：生产上线时将hotfix代码合并到master分支，并打tag，tag名称为“tag-版本号-功能编号”，从master打包上线。
总体说明
管理人员与开发人员长期的使用的分支有两个master分支和develop 分支，其他的辅助分支hotfix分支紧急bug修复时使用，feature分支为功能模块开发分支，作为开发人员可选分支，只要保证develop分支不冲突，本身代码管理清晰即可。release分支作为测试分支，其生命周期在合并到develop或master上之后就基本结束，所以大家要养成良好的习惯，在分支生命周期结束之后尽快删除掉，以免堆积太多的分支而导致混乱；
开发过程中要勤提交、勤合并，原则上一些方法级别、类级别或单元测试级别的修改可以发起一次提交，提交的commit message写明工作的内容，一个feature或bug的自测完成可以发起一次merge request，merge request的message内容要复制功能任务的描述以及具体的开发工作内容描述，切勿堆积很大的工作量才发起合并
0 条评论
下一页
