常见Git分支使用方式

§1 常备分支说明

回退分支：这是一个随时可以打包上线的分支，一般是主分支
上线分支：正常的上线操作使用的分支
开发（主/基本）分支：当前正在开发的大版本的开发分支，理论上要求随时可以提测
测试分支：通常用于提测的分支
开发子分支：从开发分支中拆分出来的子任务分支，或者分配给不同研发人员的独立子分支
预合并分支：专门用于合并代码，防止不熟练的合并操作导致某分支崩盘
bug分支：对于比较复杂的bug，建议通过一个分支进行修复

回退分支和上线分支有时使用同一个分支，或者说是不指定回退分支，因为当项目集成了自动部署平台的话，一般平台会提供更方便快捷的回退操作，如果没有集成自动部署平台问题也不大，因为有历史包存在

预合并分支是一种比较特殊的分支，它们没有实际作用，唯一存在的意义是方式不恰当的合并代码合崩了整个分支（有时也是代码的变动本身导致的），以致造成比较严重的后果

通常这些后果不是不能挽回，但是很麻烦：经历过一次test分支崩溃，从主分支重新拉取，修改配置和部分代码，通知所有相关人员重新提交测试部分的代码到此分支，攻击耗时一天半

§2比较推荐的分支设置

	分支名	分支类型	功能	说明
1	/	回退分支		不设立
2	master	上线分支
3	pre-release	预合并分支	用于从开发基本分支合并代码	很有必要
4	dev-b1.3	开发基本分支	通常用于合并到pre-release，以及用于回归测试	里面的代码要求可以随时提测，b是base的意思
5	dev-b1.3-xxx	开发子分支	从开发基本分支拆分，一般按功能拆分，特别独立的不用带基本分支标识	通常最多拆分两级，功能/模块和开发人员，子分支名尽量有意义能区分
6	test	测试分支
7	pre-test	预合并分支		比较有必要，在快速迭代定制化需求时基本必须
8	dev-b1.2-bug-xxx	bug分支	项目进入正轨后需要	不是所有的bug都需要bug分支，不是所有的项目都需要bug分支

§3 基于上面分支设置的开发分支使用举例

前提假设：当前开发的大版本叫1.3 ，包含两块功能的开发，模块OS的重构/权限机制扩展

开发中涉及分支的操作如下：

• 从master上拉取dev-b1.3分支作为开发主分支
• 从dev-b1.3拉取两个开发子分支，dev-b1.3-osrefactor（若功能比较依赖版本推荐带着版本号），dev-previlige-extend（若功能足够独立，可以考虑省略版本号）
• 假如，dev-b1.3-osrefactor的任务比较重，由两个人协同完成，一人负责内部逻辑，另一人负责封装对外接口。若开发工作足够独立且项目是允许的，可以进一步拉取两个分支 dev-b1.3-osrefactor-mem1、dev-b1.3-osrefactor-mem2。对外接口的分支优先提供接口代码和对应包到dev-b1.3-osrefacor分支，随后两人并行开发。注意，若项目拆分或分包不合理可能导致一部分功能不能拆分，只能两人共同开发同一个分支；另外，涉及大部分解耦，但一定程度上耦合的任务，可以通过先行订立接口完成完全解耦，但这要求比较良好的接口思想和相关工作协同方法，否则订立接口的一方来回改接口会很影响另一个研发人员的进度和心情。
• 开发子分支的开发完成时，必须经过自测（实际上只有自测完才叫开发完成），至少保证正向逻辑
• 提测，主要进行冒烟测试，向测试分支提测原则上不强制要求使用pre-test分支
• 根据测试反馈进行优化和修正，直到保证子分支的代码正确
• 若先行提交代码影响项目运行，需要等待协同的同学开发提测完成才能一起提交代码，否则可以先行提交，子开发分支必须先提交到主开发分支上，主开发分支上的代码必须随时可以合并到测试分支，且不影响测试工作
• 主开发分支提测，进行第二轮冒烟测试和回归测试，并同之前一样根据反馈修正修复分支内容，修复时，要在子分支上进行，但此时，自测后可以考虑直接合并到开发主分支，知道主分支没有问题
• 当功能开发完全后，可以由负责人合并代码到dev-b1.3；若基础版本内容较多，具有合并难度，可以考虑让所有研发，从自己的分支合并代码到pre-release分支（原则上禁止简单合并之外的合并他人代码），并通过测试或沙盒环境验证
• 由上线管理员将pre-release分支的内容合并到master分支并上线

§4 常用各分支操作流程示意图