GIT分支规范 ​

分支名 ​

常用的分支名有: main、dev、feat、fix、hotfix，其他分支名都不再允许。

其中:

• main 主分支，长期保留。
• dev 开发主分支，受保护，长期保留。
• feat/分支名 功能分支，PR至dev后被删除
• fix/分支名 开发功能问题修复分支，PR至dev后被删除
• hotfix/分支名 生产问题修复分支，PR至main后被删除

多版本分支名

一般情况下客户定制等特殊情况拉取分支进行开发，如果当前仓库需要保留多个不同版本分支，请使用以下格式

• 开发分支(多版本): dev/*
• 主分支(多版本): main/*

延期或暂停分支名

在遇到需求开发过程中，由于产品变更、项目变更导致的需求不可实现、延期及短期不开发的情况，请使用以下格式

以 delay/* 开头，示例如下:

# 延期或暂停需求: 增加事件驱动
delay/feat/add-event-driver

# 延期或暂停需求: 增加事件驱动
delay/feat/add-event-driver

注意

• 除dev、main、delay等开头的分支名，其他分支名不允许长期保留在仓库中

Tag ​

内部项目

格式: V版本号_日期，如 V1.0.0_20240104

客户项目

格式:客户简称_版本号_日期，如 GUOSEN_1.0.0_20240101

开发流程 ​

• 从dev分支根据需求检出feat/xxx，即 dev --> feat/xxx
• 提交PR合并至dev分支，构建测试，即 feat/xxx --> dev
• 测试: 从 feat/xxx提交PR合并或推送至dev分支，使用dev构建测试，即 feat/xxx --> dev
• 问题修复: 从dev分支检出fix/xxx，修复完成后合并至dev，即 dev --> fix/xxx --> dev
• 生产修复: 从main分支检出hotfix/xxx，修复完成后使用hotfix分支部署测试,测试完成后合并至 main、dev，即 main --> hotfix/xxx --> main、dev

上线流程 ​

• 确保所有研发分支都已 merge 到 dev分支
• 使用dev分支进行测试，发现bug，对应的bugfix merge到dev分支
• dev分支合并至main上线

Bugfix流程 ​

• dev的bug，直接检出 fix/xxx 修正,修复完成测试通过后，merge 进 dev 分支； 即 dev --> fix/xxxx --> dev

• feat分支中的bug，直接在 feat/xxx 分支修复

Hotfix流程 ​

• 从main检出hotfix/xxx修正，修复完成使用此分支测试通过后,merge 进 dev、main 分支,即 main -> hotfix -> dev、main

其他 ​

• 涉及到版本同时迭代问题，进相关人员讨论后确定分支开发方案
• 代码合并前是否需要代码评审，由项目负责人制定

主分支名修改 ​

不知master如何修改为main？