一、目的
通过标准化的流程和最佳实践，确保代码组织清晰、版本控制高效、变更管理有序，从而提高软件开发的质量、效率和可维护性，支持团队协作和持续集成/持续部署流程，最终实现项目的长期成功和发展
二、分支命名规范
-
简洁明了：使用英文小写字母和下划线，避免使用特殊字符。
-
易于识别：通过命名能够快速识别分支的用途和所属项目。
-
统一规范：确保所有团队成员遵循相同的命名规则。
| 分支名称 | 分支命名 | 功能介绍 | 约束 | 对应环境 |
| 主干分支 | 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、新功能开发流程
-
新的迭代开始，所有开发人员从主干dev拉个人分支开发特性, 分支命名规范 feature-name（根据项目实际情况可以省略特分支，此分支就是个人远程仓库，防止直接合入开发分支，通过提交merge的方式，只有代码检视通过才能合入，提升代码库质量）--这里可以增加自动代码审查。
-
开发完成后，通过自测，本地代码质量扫描合入dev分支
-
将本次迭代转测所有代码部署到dev环境，完成集成测试，并通过代码质量检查
-
基于dev拉取要发布的分支，release/xxx（如果创建好则跳过），将这个分支部署到测试环境进行测试
-
验收测试通过后，基于release/xxx发布版本。
-
待版本发布稳定后，将release/xxx同步到master，同时在 Master 分支上打个 Tag 记住 release 版本号，然后可以删release/$version
3、修复线上Bug（hotfix分支）
-
从
master分支某个tag上创建一个hotfix分支（热修复分支），一般是最新的tag应该和当前生产环境对应 -
开发人员完成Bug 修复，提交
hotfix分支到测试环境验收通过 -
基于
hotfix分支发布版本 -
待版本发布稳定后，将
hotfix分支合并到dev与master分支，同时在master分支上打个 Tag 记住hotfix版本号 -
删除
hotfix分支
4、测试Bug修复流程
-
基于release/xxx分支创建fix/xxx的修复分支；
-
在fix/xxx的修复分支在开发环境自测通过，通知测试部署到测试环境验证；
-
测试验证通过，研发将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分支；
六、分支的删除规范
-
修复分支：
– hotfix/xxx 合并到master与dev分支可以删除，fig/xxx合并到dev和release/xxx 可以删除。
-
发布分支：
– release/xxx合并到master后可以产出。
-
注意事项：
– 删除分支前，确保该分支的代码已经合并回了相应的主分支，并且不再需要保留。
七、其他注意事项
-
定期进行分支清理，避免分支过多导致管理混乱。
-
团队成员应定期培训和交流，确保对分支管理规范有深入理解和遵循。
-
遵循敏捷开发原则，灵活调整分支管理策略以适应项目需求变化。