git 分支管理规范

代码分支管理规范

分支管理总图

分支命名规范

1、功能开发分支：feature- (预期发布日期)-(功能特性名称)， -
案例：feature-0424-审批场景管理
2、线上和预发bug修复分支：hotfix_(修复的bug的英语简写)_(计划发布时间)_(分支拉取时间)
案例：hotfix_vpptime_0415_20250407
3、技术改造分支：tech_(改造内容的英语简写)_(计划发布时间)_(分支拉取时间)
案例：tech_mutilange_0415_20250407

操作规范说明

1. 任何需求开发分支都需要从Prerelease分支作为基线拉代码开发

2. develop、test、prerelease、production分支都不允许直接提交代码，需要把分支做好保护，只能通过merge request合并代码。

   develop、test、prerelease、production 它们都有对应的服务器环境。

3. 所有需求的开发都从仓库网页创建分支；这个功能的所有bug的修改都在这个分支【说明分支要长期存在，直到上生产】。

4. 提测的时候，都是通过merge request合并到test分支，避免从develop直接合并到test。

   • develop分支会有别人的脏代码，不能直接和到test分支上。

   • 同样道理，test分支也不能直接合并到预发分支，test分支可能有别人没有没有通过测试的代码。

   • prerelease 没有问题，是直接合并到 production上的（仓库网页上合并请求）。

5. 如果2个迭代有并行再test分支进行测试了，那也需要通过各个特性分支独立merge request合并到prerelease分支，如果test是只包含一个迭代分支，则 可以test直接merge request合并到prerelease。

   习惯了都是直接功能分支合并到prerelease，一般都不止一个人开发，即多个并行迭代分支。

6. 如果出现了分支合并冲突，比如从“issues/C2025031400548-0424-审批场景管理“发起merge request合并test分支报代码冲突了，那从test分支拉 取一个conflict_fix_0424_20250407分支，把“issues/C2025031400548-0424-审批场景管理“合并到conflict_fix_0424_20250407，解决完冲突后，在把conflict_fix_0424_20250407 merge request合并test分支。

7. commit的编写规范：^(revert: )?(feat|fix|docs|style|refactor|perf|test|chore|ci|build|release)((.+))?: .{1,50}