框架类版本管理分支规范
在企业内部关于代码项目的类型大致可以分为两类，业务型代码与框架型代码。业务型代码即以业务快速迭代，有完善的业务测试并交付；框架型代码主要是对针对所有业务代码做一些通用型下层，或一些工具类，或开源项目扩展集成等。这两类项目在Git分支协作使用方式上，还是有点不同。
业务型代码可以采用GitFlow这类型协作方式，并且有一些GUI工具都支持GitFlow，如GiKraken，SourceTree等。有人也会说GitFlow不好，比如使用阿里的AoneFlow模式会更好，其实一般中小心型企业有GitFlow来做业务代码的分支规范，有现成的工具是最好的选择了，至于想用AoneFlow模式的也可以，但是要自己在发布系统上做相应的分支操作逻辑等。
框架型代码一般来说不是以周期性迭代交付的，而是要求稳定的功能输出，既要有稳定的版本，也要有新功能的加入，这里用Trunk-Based分支模式比较适合。
今天要分享的就是框架型代码的版本管理分支规范，参考了Trunk-Based并做了相应的处理规范。
我们框架类型的项目采用的版本管理参考Dubbo的方式，这里需要对Git分支管理做一个补充。
版本管理
新功能的开发 和 稳定性的提高 对产品都很重要。但是添加新功能会影响稳定性，Dubbo 使用如下的版本开发模式来保障两者。
- BugFix 版本：低版本，比如
2.4.x。是 GA 版本，线上使用的版本，只会 BugFix，升级第三位版本号。 - 新功能版本：高版本，比如
2.5.x。加新功能的版本，会给对新功能有需求的应用试用。
2.5.x 的新功能基本稳定后，进入 2.5.x 试用阶段。找足够多的应用试用 2.5.x 版本。
在 2.5.x 够稳定后：
2.5.x成为 GA 版本，只 BugFix，推广使用此版本。如何可行，可以推进应用在期望的时间点内升级到 GA 版本。2.4.x不再开发，应用碰到 Bug 让直接升级。（这个称为“夕阳条款”）- 从
2.5.x拉成分支2.6.0，作为新功能开发版本。
分支管理
由于框架类的代码管理不同于业务代码，这里抛弃GitFlow严格的模型，借鉴TrunkBased模型，定下如下分支管理规范。
根据GA版本与Feature版本，我们需要两个并行主干分支，假设当前的GA版本是2.5.x，那么主干分支如下：
- master分支：作为当前Feature主干分支（2.6.x），做新功能开发。
- 2.5.x分支：作为当前GA主干分支，只做bug修复。
当Feature版本2.6.x足够稳定后：
- 2.6.x成为新的GA版本，就从当前的master创建新分支
2.6.x，作为新的GA分支 - master分支则成为新的Feature分支，即2.7.x
- 旧的GA版本2.5.x分支停止开发维护，应用碰到Bug直接升级新版GA（“夕阳条款”）
release发布
无论是GA版本，还是Feature版本，都需要发布具体的版本，这里都统一使用同样的逻辑。
如Feature版本，即所在master分支：
- 在master分支修改代码中的版本号为RELEASE类型
- 提交并创建相应的tag，
v2.7.0，然后push - 在利用该tag发布代码
- 在master分支修改代码中的版本号为SNAPSHOT类型
如GA版本，即所在的2.6.x分支
- 在2.6.x分支修改代码中的版本号为RELEASE类型
- 提交并创建相应的tag，
v2.6.0，然后push - 在利用该tag发布代码
- 在2.6.x分支修改代码中的版本号为SNAPSHOT类型
bug修复
由于有两个并行主干分支，所以修复bug时需考虑两种情况：
- Feature版本无需修复，只需GA版本修复
- Feature版本和GA版本，需要同时修复Bug
1）只需GA版本修复
这种情况比较简单，直接在当前的GA分支上提交修复bug即可。如在GA版本分支2.6.x上修复
2）需要同时修复
两个分支需要同时修复时，这里我们不考虑merge的方式，这样会使分支结构不清晰，我们采用
cherry-pick的方式，操作如下：
- 在当前的Feature版本，即master分支上，修复bug，并提交
- 切换到GA版本，将master分支上的bug修复提交
cherry-pick到当前分支
以上方式就是bug修复的逻辑。
如果需要修复完就发布，就类似于hotfix，我们不采用hotfix分支，直接按上面的release发布逻辑即可。
feature分支
理论上来说新特性统一在Feature版本中实现，即直接在master分支开发实现即可。但如果实在有些试验性的新功能需要开发，并且不想纳入当前的Feature版本，那么我们可以这样操作：
- 在当前的master分支，创建新分支feature/xxx
- 在新的feature分支开发
- 当需要纳入Feature版本时，切换到master分支，merge该功能分支
提交注意
多人协作开发时，会在同个分支提交代码，如果遇到本地分布与远程分支有分叉时（即push不上去），这是尽量不要使用pull，而是采用rebase的方式。
如将本地master分支rebase到origin/master分支，保持分支的整洁性。
分支示意图
