模式分析

分支管理主要分为TrunkBased 模式、GitFlow模式，在这些模式的基础上演变出了其它使用实践。

TrunkBased 模式：持续集成

What is Trunk-Based Development?
谷歌的代码管理 - 阮一峰的网络日志

TrunkBased 模式是持续集成思想所崇尚的工作方式，它由单个主干分支和许多发布分支组成，每个发布分支在特定版本的提交点上从主干创建出来，用来进行上线部署和 Hotfix。
不能满足多版本并行开发，主要用在不需要同时维护多个历史版本的 SaaS 型项目，特别是经过微服务改造的各种小型服务上。
OneFlow 模式：参考了 TrunkBased 的许多思想，对操作流程做了更严格的定义，增加了 Hotfix 分支等内容。
多主干模式：通常是双主干，固定的开发分支和固定的发布分支，算是 TrunkBased 采用固定发布分支的特例。
GithubFlow 模式：在 TrunkBased 的基础上，增加了个人仓库和 Pull Request 合并代码的操作。

GitFlow模式：管理需求

深入理解学习Git工作流（git-workflow-tutorial） - 程序生涯 - SegmentFault 思否
GitFlow模式相对强大：

应用一：

master分支：主分支，产品的功能全部实现后，最终在master分支对外发布。
develop分支：开发分支，基于master分支克隆，产品的编码工作在此分支进行。
release分支：测试分支，基于delevop分支克隆，产品编码工作完成后，发布到本分支测试，测试过程中发现的小bug直接在本分支进行修复，修复完成后合并到develop分支。本分支属于临时分支，目的实现后可删除分支。
bugfix分支：Bug修复分支，基于master分支或发布的里程碑Tag克隆，主要用于修复对外发布的分支，收到客户的Bug反馈后，在此分支进行修复，修复完毕后分别合并到develop分支和master分支。本分支属于临时分支，目的实现后可删除分支。
feature分支：功能特征分支，基于develop分支克隆，主要用于多人协助开发场景或探索性功能验证场景，功能开发完毕后合并到develop分支。feature分支可创建多个，属于临时分支，目的实现后可删除分支。

gitflow模型.png

主要问题有：

::1、如果测试后不上线，Develop分支与线上分支不一致，如果需要develop分支与master一致就需要频繁重建develop分支或回滚。::
::2、另外release merge到Master时，代码冲突严重。::

应用二：

与应用一的区别是：建立发布分支用于发布，发布后合并master。
1、共一个主干分支master
2、N个特性分支==N个发布分支（特性分支开发完成后，直接转测，直接转为发布分支）
3、不定期的更新主干分支

主要问题有：

::1、主干分支常常跟不上线上环境的代码::
::2、大量的合并突冲，集成测试不友好::

TrunkBased与GitFlow比较：

优点：

TrunkBased “易于持续集成” ; GitFlow “易于管理需求”

缺点：

TrunkBased缺点：不能很好支持多版本的并行开发
GitFlow的问题：合并冲突

阿里分支管理AoneFlow

在 AoneFlow 上你能看到许多其他分支模式的影子。它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点，同时规避掉 GitFlow 的那些繁文缛节。

AoneFlow.jpg

1、开始工作前，从主干创建特性分支。

AoneFlow-add feature.png

2、通过合并特性分支，形成发布分支。

AoneFlow-add-release.png

3、发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。

AoneFlow-merge master.png

京东分支管理：

分支分类：

master：主分支，与线上保持一致。永久保留。
dev：开发分支，相对稳定分支。永久保留。dev分支与master强一致
dev-pretest ： 测试和预上线分支，必要的时候删除从dev拉取。
feat-人名全拼或者姓名首字母-功能描述： 功能分支。如; feat-sunweiwei-cancelorder或者feat-sww-cancelorder，标注开发人员+该分支的功能。用完即删。
hotfox-人名全拼或者姓名首字母-功能描述：线上bug修复分支。如：hotfix-sunweiwei-orderpay或者feat-sww-orderpay，标注开发人员+该分支处理的问题。用完即删。
分支名称统一都是小写字母。

jd.jpg

京东与阿里的比较

相同：都从主干拉取分支，再合并特性分支，减少了合并冲突
不同：京东是直接在master分支上发布，阿里是新建发布分支，发布成功后合并到master，
两种方式导致的结果是：阿里支持“修改历史版本bug”的功能，京东不支持。

::总的来说，京东偏向TrunkBased 模式，阿里偏向Gitflow模式，由于京东模式缺少明确的发布分支，只在主干分支上发布，导致不支持多版本，如果要修改历史版本的bug，只能升级到最新版本。::

总结：

::1、对于微服务中小型服务（或只是一个jar工具包），这种修改后立刻可以上线使用，且不影响线上服务的情况，用TrunkBased 模式即可::
::2、如果系统不支持多版本修复（需要修复升级到最新版本即可），使用京东方式即可。如果有多版本支持使用阿里方式。::

以上讨论基于如下需求：
1、多功能同时测试
2、测试后可能不上线

参考：

在阿里，我们如何管理代码分支？
GitHub Flow & Git Flow 基于Git 的两种协作开发模式 - sloong - 博客园