一、目的

通过标准化的流程和最佳实践，确保代码组织清晰、版本控制高效、变更管理有序，从而提高软件开发的质量、效率和可维护性，支持团队协作和持续集成/持续部署流程，最终实现项目的长期成功和发展

二、分支命名规范

• 简洁明了：使用英文小写字母和下划线，避免使用特殊字符。

• 易于识别：通过命名能够快速识别分支的用途和所属项目。

• 统一规范：确保所有团队成员遵循相同的命名规则。

分支名称	分支命名	功能介绍	约束	对应环境
主干分支	master	用于线上部署的稳定代码	只接受合并请求，每次发布打上Tag标签	生产环境
开发分支	dev	用于整合开发成员的代码的主干分支，从master分支创建		开发环境
发布分支	release/xxx	用于发布新版本的分支，xxx为版本号，从develop分支创建，最终合并回maste分支	只接受合并请求	测试/UAT/生产环境
修复分支	hotfix/xxx	用于修复线上紧急bug的分支，xxx为版本号，从master分支创建并合并回master和develop分支。		测试环境
修复分支	fix/xxx	用于修复转测的bug。从release/xxx创建，xxx为迭代编号+转测编号，如fix/1.6就是迭代1第6次转测，最终合并到release/xxx和dev分支		开发环境，测试环境

三、分支的使用和管理规范

1、源码仓库初始化

当接收到正常的业务需求时，项目经理/开发主管根据架构设计在gitlib上创建初始版项目，全英文小写，中间用_作为连接符：

• 后端代码以_service后缀

• 前端代码以_web后缀

• 移动端代码以_app后缀

创建分支，项目创建为master分支为主干分支，基于master创建dev分支，基于dev创建release分支（如果版本没确定可以放到转测时创建），设置三分支均为受保护分支，且master/release分支只有Maintainer角色可以合并。

注：Maintainer角色只能授予PM、测试组长、技术组长

2、新功能开发流程

1. 新的迭代开始，所有开发人员从主干dev拉个人分支开发特性, 分支命名规范 feature-name（根据项目实际情况可以省略特分支，此分支就是个人远程仓库，防止直接合入开发分支，通过提交merge的方式，只有代码检视通过才能合入，提升代码库质量）--这里可以增加自动代码审查。

2. 开发完成后，通过自测，本地代码质量扫描合入dev分支

3. 将本次迭代转测所有代码部署到dev环境，完成集成测试，并通过代码质量检查

4. 基于dev拉取要发布的分支，release/xxx（如果创建好则跳过），将这个分支部署到测试环境进行测试

5. 验收测试通过后，基于release/xxx发布版本。

6. 待版本发布稳定后，将release/xxx同步到master，同时在 Master 分支上打个 Tag 记住 release 版本号，然后可以删release/$version

3、修复线上Bug（hotfix分支）

1. 从 master 分支某个 tag 上创建一个 hotfix 分支（热修复分支），一般是最新的 tag 应该和当前生产环境对应

2. 开发人员完成Bug 修复，提交 hotfix 分支到测试环境验收通过

3. 基于hotfix分支发布版本

4. 待版本发布稳定后，将 hotfix 分支合并到dev与master 分支，同时在 master 分支上打个 Tag 记住 hotfix 版本号

5. 删除 hotfix 分支

4、测试Bug修复流程

1. 基于release/xxx分支创建fix/xxx的修复分支；

2. 在fix/xxx的修复分支在开发环境自测通过，通知测试部署到测试环境验证；

3. 测试验证通过，研发将fix/xxx分支代码同步到release/xxx与dev分支，同时删除fix/xxx分支；

四、提交内容规范

Git 每次提交代码，都要写 Commit message（提交说明），否则就不允许提交。但是，一般来说，commit message 应该清晰明了，说明本次提交的目的。提交规范设置为：" type:subject "

type

用于说明 commit 的类别，只允许使用下面7个标识。

• feat：新功能（feature）

• fix：修补bug

• docs: 仅文档更改

• style：格式（不影响代码运行的变动）

• refactor：重构（即不是新增功能，也不是修改bug的代码变动）

• revert：回滚到上一个版本

• test：增加测试

subject

subject 是 commit 类型的简短描述，建议不超过50个字。

五、提交分支规范

• 禁止向主分支直接提交代码，包括代码仓库在线编辑修改；

• 禁止提交测试性代码到任何主分支源码（src）目录，测试代码只能存在于测试（test）目录；

• 禁止任何工作分支跨主分支提交代码，工作分支从只能合并到与工作分支同源的主分支；

• 必须备注每一次提交，代码备注必须简要可读。准确的描述具备可检索性；

• 必须备注每一次合并请求，对合并请求包含的功能点简要描述。准确的描述具备可检索性。

• 必须每次提交之前本地完成代码质量扫描；

• 必须完成代码质量扫描才能合入release/xxx分支；

六、分支的删除规范

1. 修复分支：

– hotfix/xxx 合并到master与dev分支可以删除，fig/xxx合并到dev和release/xxx 可以删除。

1. 发布分支：

– release/xxx合并到master后可以产出。

1. 注意事项：

– 删除分支前，确保该分支的代码已经合并回了相应的主分支，并且不再需要保留。

七、其他注意事项

• 定期进行分支清理，避免分支过多导致管理混乱。

• 团队成员应定期培训和交流，确保对分支管理规范有深入理解和遵循。

• 遵循敏捷开发原则，灵活调整分支管理策略以适应项目需求变化。