史上最全分支管理策略说明及优缺点

1.Git Flow模型

1.1.Git Flow模型简介

Git Flow模型中定义了主分支和辅助分支两类分支，其中主分支用于组织与软件开发、部署相关的活动；辅助分支组织用于解决特定的问题而进行的各种开发活动。

1.2.分支管理

1.2.1分支说明

模型的特点是只有2个主干分支，Master和Develop分支：Master分支上只有稳定的生产版本，Develop分支用于集成。其中还涉及到HotFix分支。而其他还有三类分支：Feature分支用于开发人员各自开发；Release用于代码合并和集成；HotFix用于产品版本代码的紧急修订。下图是经典的模型图

1.2.2、主分支

主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和develop分支。

A、master分支
通常，master分支只能从其它分支合并，不能在master分支直接修改。master分支上存放的是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动到一定阶段，产生一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签（TAG）。
所有在Master分支上的Commit应该打Tag。
B、develop分支

1. develop分支是保持当前开发最新成果的分支，一般会在此分支上进行晚间构建(Nightly Build)并执行自动化测试。
2. develop分支产生于master分支, 并长期存在。
3. 当一个版本功能开发完毕且通过测试功能稳定时，就会合并到master分支上，并打好带有相应版本号的tag。
4. develop分支一般命名为develop
   develop分支是主开发分支，包含所有要发布到下一个Release的代码，主要合并其它分支，比如Feature分支。

1.2.3、辅助分支

辅助分支是用于组织解决特定问题的各种软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。辅助分支通常只会在有限的时间范围内存在。
辅助分支包括用于开发新功能时所使用的feature分支，用于辅助版本发布的release分支，用于修正生产代码中的缺陷的hotfix分支。
辅助分支都有固定的使用目的和分支操作限制。通过对分支的命名，定义了使用辅助分支的方法。
A、feature分支
feature分支使用规范：

1. 可以从develop分支发起feature分支。
2. 代码必须合并回develop分支。
3. feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名称。
   feature分支（topic分支）通常在开发一项新的软件功能的时候使用，分支上的代码变更最终合并回develop分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。
   一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
   Feature分支开发完成后，必须合并回Develop分支，合并完分支后一般会删Feature分支，但也可以保留。
   

B、release分支
release分支使用规范：

1. 可以从develop分支派生；
2. 必须合并回develop分支和master分支；
3. 分支命名惯例：release-*；
   release分支是为发布新的产品版本而设计的。在release分支上的代码允许做测试、bug修改、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等）。通过在release分支上进行发布相关工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。
   当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，可以考虑准备创建release分支。而所有在当前即将发布的版本外的业务需求一定要确保不能混到release分支内（避免由此引入一些不可控的系统缺陷）。
   成功的派生release分支并被赋予版本号后，develop分支就可以为下一个版本服务。版本号的命名可以依据项目定义的版本号命名规则进行。
   发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后就可以删除Release分支。
   

C、hotfix分支
hotfix分支使用规范：

1. 可以从master分支派生；
2. 必须合并回master分支和develop分支；
3. 分支命名惯例：hotfix-*；
   hotfix分支是计划外创建的，可以产生一个新的可供在生产环境部署的软件版本。
   当生产环境中的软件遇到异常情况或者发现了严重到必须立即修复的软件缺陷时，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。优点是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。
   hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag。
   

1.3.评价

Git Flow开发模型从源代码管理角度对通常意义上的软件开发活动进行了约束，为软件开发提供了一个可供参考的管理模型。Git Flow开发模型让代码仓库保持整洁，让小组各个成员之间的开发相互隔离，能够有效避免处于开发状态中的代码相互影响而导致的效率低下和混乱。

• Git flow的优点是清晰可控
• 缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发是在develop分支进行的，这导致经常要切换分支

2.Github flow模型

2.1.Github flow模型简介

Github flow 是Git flow的简化版，专门配合”持续发布”。它是 Github.com 使用的工作流程。

2.2分支管理

2.1.1创建分支（Create a branch）

第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。

2.2.2添加提交

第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。

2.2.3提出 Pull 请求

第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。

2.2.4讨论和评估你的代码

第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）

2.2.5. 部署

只要你的 Pull 请求被审查并且通过了你的测试，你就可以部署这些修改，在生产环境中验证她们。如果分支发生了问题，你也可以回滚到之前的状态。

2.2.6合并

2.3. 评价

• 优点:简单，对于”持续发布”的产品，可以说是最合适的流程。
• 缺点:问题在于它的假设：master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上代码。可是，有些时候并非如此，代码合并进入master分支，并不代表它就能立刻发布。比如，苹果商店的APP提交审核以后，等一段时间才能上架。这时，如果还有新的代码提交，master分支就会与刚发布的版本不一致。

3.Gitlab flow模型

3.1.简介

Gitlab flow 的最大原则叫做”上游优先”（upsteam first），即只存在一个主分支master，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支。
对于”持续发布”的项目，它建议在master分支以外，再建立不同的环境分支。比如，”开发环境”的分支是master，”预发环境”的分支是pre-production，”生产环境”的分支是production

只有紧急情况，才允许跳过上游，直接合并到下游分支。
对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。

3.2分支管理

1. 新的迭代开始，所有开发人员从主干master拉个人分支开发特性, 分支命名规范 feature-name
2. 开发完成后，在迭代结束前，合入master分支
   master分支合并后，部署到dev环境
3. 开发自测通过后，从master拉取要发布的分支，release-$version，将这个分支部署到测试环境进行测试
4. 测出的bug，通过从release-$versio拉出分支进行修复，修复完成后，再合入release-$versio
5. 正式发布版本，如果上线后，又有bug，根据5的方式处理
   等发布版本稳定后，将release-$versio反合入主干

3.3评价

Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。
• 优点：不用管那么多分支；每个分支合并后都有对应版本号；
• 缺点：针对中小型团队是可以的，稍大点的团队不能满足多分支管理。

4.TrunkBased

4.1.简介

• 为解决冲突而生的git工作流，2类分支（master、发布分支），1个主分支（master）；
• 所有人在master分支上开发；
• 分支随时满足发布，需要发布时候创建发布分支，并打上版本号

4.2.分支管理

Trunk Based只有一个master主干，每个人都在本地写新代码，达到可提交程度的时候，就往master合并。如下图：

1. 这种模式在本地和 master 之间不存在一个缓冲的区域，所以从本地 commit 到 master 时，需要确保经过了本地测试可用。
2. 过程足够简单，节省项目一致性成本。
3. 对项目或产品计划要求不高。有基本的WBS，任务计划，里程碑计划就行了。而且由于计划复杂度要求不高，修改计划的成本也就比较低。这点最本质的说法，就是产品只有一个 release线。
4. ABC三个模块同时开发时，一旦决定只上线AB模块，由于都在 master，线上版本其实也包含C模块的部分。当然可以也有办法去回避这个问题，比如 Feature Toggle，功能开关。

4.3评价

优点：模型简单
缺点：
• 线上修正：按照上图目前系统已经发布了12.1，下一个迭代也在开发中，线上发现了问题。由于Release分支是禁止修改的，而Trunk此时包含了新的特性代码无法发布，就造成了线上异常无法修复。
• 需求变更：无法支持，已经提交到Trunk的内容抽离很困难。
• 多环境：无法支持
• 长期需求：无法支持

5.AoneFlow

5.1简介

阿里的git工作流；3类分支（master、特性分支、发布分支），1个主分支（master）

5.2分支管理

规则一，开始工作前，从master创建feature分支。
从代表最新已发布版本的master分支上创建一个通常以feature/前缀命名的特性分支，然后在这个分支上提交代码修改。也就是说，每个工作项（可以是一个人完成，或是多个人协作完成）对应一个特性分支，所有的修改都不允许直接提交到master分支。

规则二，通过合并feature分支，形成release分支。
从master分支上拉出一条新分支，将所有本次要集成或发布的feature分支依次合并过去，从而得到release分支。release分支通常以release/前缀命名。

规则三，发布到线上正式环境后，合并相应的release分支到master分支，在master分支上添加tag，同时删除该release分支关联的feature分支。
为了避免在代码仓库里堆积大量历史上的feature分支，还应该清理掉已经上线部分feature分支。如果要回溯历史版本，只需在master分支上找到相应的版本的tag即可。

5.3评价

1. AoneFlow 的发布分支是相对固定的，因此相比 GitFlow 更易于进行持续集成。
2. 经过阿里团队长期实践，稳定性很高。项目管理相比却更加容易和高效，去除一些繁琐步骤。
3. 每次有新需求时，从当前主干分支拉取一个特性分支。多个特性分支可同步开发，到发布时间节点时，根据不同的环境合并不同的分支。
4. 对于维护不同环境和不同版本的情况下非常适用，不会产生多余的分支，主干分支与线上环境保持一致。
   • 优点：灵活的安排发布分支，支持长时分支；
   • 缺点：有长时分支，就会有冲突。