基本代码分支应该分为两类，一类是主要分支，包括线上主分支 Master 和开发主分支
Develop；另一类是辅助分支，包括测试分支 Release，线上紧急修复分支 Hotfix，以及功能
开发分支 Feature。
● Master 分支上的所有代码节点都必须处于可发布状态，且与线上运行的版本对应并且每一个
节点都生成了 Tag 标注了发布的版本 ID。
● Develop 分支上的代码节点代表了最新的功能开发进度，用于日常的功能开发，集成了多个新
开发的功能以及正式提测前的 bug 修复代码。
● Feature 分支用于管理功能的并行开发（命名建议为”feature-*”） ，起源于 Develop 分支，最终
也会归于 Develop 分支（要求采用--no-ff 的方式进行分支合并，以确保整个提交链的完整
性） 。
● Release 分支主要用于正式的测试并帮助构建可发布的代码（命名建议为”release-*”） ，起源于
Develop 分支，最终归于“develop”及“master”分支。正式提测后的 bug 修复必须在此分支上进
行，并且需尽量避免新功能的并入。每次当 Release 代码合并到 Master 分支时都必须反向合
并回 Develop 分支。
● Hotfix 分支用于紧急修复线上运行版本的关键 BUG（命名建议为”hotfix-*”） ，hotfix 分支基于
Master 分支创建，开发完后需要合并回 Master、Release 和 Develop 分支，同时在 Master
上打一个 Tag。
Release 和 Master 分支须受到保护，必须有固定的一到两名人员负责分支的合并操作。
提测规范
● 持续集成应用接入 QA 环境需根据线上最新版本代码做一次初始化
● 每次提交代码都需正确填写备注（功能描述） ，每次发版都要打 Tag 标签
● 提测期间有问题，基于 Release 分支修改，测试通过后基于 Release 发布
● 线上紧急 bug从 Master 拉 Hotfix 分支修改，合并至 Master 发版修复
● SA 组除 HotFix 外的发版均基于提测通过的 Release 分支
代码管理准则
● 创建分支要有计划性，尽可能的控制分支的数量
● 低版本总是积极的合并到高版本，同时注意反向合并
● 每次提交及合并的日志须完整规范，说明修改部分的意图
● 发起合并的版本务必经过冒烟自测及代码评审
● 珍惜每次提测，提测内容与修改内容相符
原文地址：https://www.cnblogs.com/shy1766IT/p/8269901.html