1 TBD(Trunk Based Development)
Trunk Based Development早在svn时代就已经流行，是种比较简单的分支管理模型。
典型的TBD模型如下：
特点：
他只有一个主干分支
每个人写完代码自测通过后就往主干上面Push，要发布的时候就拉个Release分支。
优点：
对持续集成友好。
缺点：
多个人开发多个功能时代码干扰比较严重；
如果临上线前发现有问题，剔除代码比较困难；
即使没有需求变更要下掉代码，有些提交如果未能达到上线标准，需要加Feature Toggle来控制打开关闭。这是一个需要平衡的事情，往往会增加一定开发成本和风险；
适用：
因相对简单，难以应对复杂情况，适用用于小型项目
2 功能分支协同工作流
上面的那种方式有一个问题，就是大家都在一个主干上开发程序，对于小团队或是小项目你可以这么干，但是对比较大的项目或是人比较多的团队，这么干就会有很多问题。
最大的问题就是代码可能干扰太严重。尤其是，我们想安安静静地开发一个功能时，我们想把各个功能的代码变动隔离开来，同时各个功能又会有多个开发人员在开发。
这时，我们不想让各个功能的开发人员都在 Master 分支上共享他们的代码。我们想要的协同方式是这样的：同时开发一个功能的开发人员可以分享各自的代码，但是不会把代码分享给开发其他功能的开发人员，直到整个功能开发完毕后，才会分享给其他的开发人员（也就是进入主干分支）。
因此，我们引入“功能分支”，如下：
就像上面这个图显示的一样，紫色的分支就是功能分支，合并后就会像上面这个样子。
3 GitFlow 协同工作流
在真实的生产过程中，前面的协同工作流还是不能满足工作的要求。这主要因为我们的生产过程是比较复杂的，软件生产中会有各式各样的问题，并要面对不同的环境。我们要在不停地开发新代码的同时，维护线上的代码，于是，就有了下面这些需求。
希望有一个分支是非常干净的，上面是可以发布的代码，上面的改动永远都是可以发布到生产环境中的。这个分支上不能有中间开发过程中不可以上生产线的代码提交。
希望当代码达到可以上线的状态时，也就是在 alpha/beta release 时，在测试和交付的过程中，依然可以开发下一个版本的代码。
最后，对于已经发布的代码，也会有一些 Bug-fix 的改动，不会将正在开发的代码提交到生产线上去。
你看，面对这些需求，前面的那些协同方式就都不行了。因为我们不仅是要在整个团队中共享代码，我们要的更是管理好不同环境下的代码不互相干扰。说得技术一点儿就是，要管理好代码与环境的一致性。
为了解决这些问题，GitFlow 协同工作流就出来了。
GitFlow 协同工作流是由 Vincent Driessen 于 2010 年在 A successful Git branching model 这篇文章介绍给世人的。
这个协同工作流的核心思想如下图所示。
整个代码库中一共有五种分支。
Master 分支。也就是主干分支，用作发布环境，上面的每一次提交都是可以发布的。
Feature 分支。也就是功能分支，用于开发功能，其对应的是开发环境。
Developer 分支。是开发分支，一旦功能开发完成，就向 Developer 分支合并，合并完成后，删除功能分支。这个分支对应的是集成测试环境。
Release 分支。当 Developer 分支测试达到可以发布状态时，开出一个 Release 分支来，然后做发布前的准备工作。这个分支对应的是预发环境。之所以需要这个 Release 分支，是我们的开发可以继续向前，不会因为要发布而被 block 住而不能提交。
一旦 Release 分支上的代码达到可以上线的状态，那么需要把 Release 分支向 Master 分支和 Developer 分支同时合并，以保证代码的一致性。然后再把 Release 分支删除掉。
Hotfix 分支。是用于处理生产线上代码的 Bug-fix，每个线上代码的 Bug-fix 都需要开一个 Hotfix 分支，完成后，向 Developer 分支和 Master 分支上合并。合并完成后，删除 Hotfix 分支。
这就是整个 GitFlow 协同工作流的工作过程。我们可以看到：
我们需要长期维护 Master 和 Developer 两个分支。
这其中的方式还是有一定复杂度的，尤其是 Release 和 Hotfix 分支需要同时向两个分支作合并。所以，如果没有一个好的工具来支撑的话，这会因为我们可能会忘了做一些操作而导致代码不一致。
GitFlow 协同虽然工作流比较重。但是它几乎可以应对所有公司的各种开发流程，包括瀑布模型，或是快速迭代模型。
优点：
可以解决实绩生产过程中各种复杂的问题；
缺点：
因为分支太多，所以会出现 git log 混乱的局面
在开发得足够快的时候，你会觉得同时维护 Master 和 Developer 两个分支是一件很无聊的事，因为这两个分支在大多数情况下都是一样的。包括 Release 分支，你会觉得创建的这些分支太无聊
整个开发过程也会因为这么复杂的管理变得非常复杂。尤其当你想回滚某些人的提交时，你就会发现这事似乎有点儿不好干了。而且在工作过程中，你会来来回回地切换工作的分支，有时候一不小心没有切换，就提交到了不正确的分支上，你还要回滚和重新提交，等等
GitLab 一开始是 GitFlow 的坚定支持者，后来因为这些吐槽，以及 Hacker News 和 Reddit 上大量的讨论，GitLab 也开始不玩了。他们写了一篇 blog来创造了一个新的 Workflow——GitLab Flow，这个 GitLab Flow 是基于 GitHub Flow 来做的
4 GitHub Flow
所谓 GitHub Flow，其实也叫 Forking flow，也就是 GitHub 上的那个开发方式。
每个开发人员都把“官方库”的代码 fork 到自己的代码仓库中。
然后，开发人员在自己的代码仓库中做开发，想干啥干啥。
因此，开发人员的代码库中，需要配两个远程仓库，一个是自己的库，一个是官方库（用户的库用于提交代码改动，官方库用于同步代码）。
然后在本地建“功能分支”，在这个分支上做代码开发。
这个功能分支被 push 到开发人员自己的代码仓库中。
然后，向“官方库”发起 pull request，并做 Code Review。
一旦通过，就向官方库进行合并。
这就是 GitHub 的工作流程。
如果你有“官方库”的权限，那么就可以直接在“官方库”中建功能分支开发，然后提交 pull request。通过 Code Review 后，合并进 Master 分支，而 Master 一旦有代码被合并就可以马上 release。
这是一种非常 Geek 的玩法。这需要一个自动化的 CI/CD 工具做辅助。是的，CI/CD 应该是开发中的标配了。
GithubFlow 模式，不过这种策略无非是在 TBD的基础上，增加了个人仓库和 Pull Request 合并代码的操作，与在同一个仓库里增加个人分支的做法类似，从实用的意义来说，它更合适分布式团队。
5 GitLab Flow
然而，GitHub Flow 这种玩法依然会有好多问题，因为其虽然变得很简单，但是没有把我们的代码和我们的运行环境给联系在一起。所以，GitLab 提出了几个优化点。
其中一个是引入环境分支，如下图所示，其包含了预发布（Pre-Production）和生产（Production）分支。
而有些时候，我们还会有不同版本的发布，所以，还需要有各种 release 的分支。如下图所示。Master 分支是一个 roadmap 分支，然后，一旦稳定了就建稳定版的分支，如 2.3.stable 分支和 2.4.stable 分支，其中可以 cherry-pick master 分支上的一些改动过去。
这样也就解决了两个问题：
环境和代码分支对应的问题；
版本和代码分支对应的问题。
6 阿里AoneFlow
阿里有很多的研发团队，不同事业部使用的发布流程、分支策略并非整齐划一，但总体上看是比较规整的。其中有一种主流的发布模式以及对应的分支使用方式，称为“AoneFlow”。
在 AoneFlow 上你能看到许多其他分支模式的影子。它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点，同时规避掉 GitFlow 的那些繁文缛节。
看一下具体套路。AoneFlow 只使用三种分支类型：主干分支、特性分支、发布分支，以及三条基本规则。
规则一，开始工作前，从主干创建特性分支。
AoneFlow 的特性分支基本借鉴 GitFlow，没有什么特别之处。每当开始一件新的工作项（比如新的功能或是待解决的问题）的时候，从代表最新已发布版本的主干上创建一个通常以feature/前缀命名的特性分支，然后在这个分支上提交代码修改。也就是说，每个工作项（可以是一个人完成，或是多个人协作完成）对应一个特性分支，所有的修改都不允许直接提交到主干。
规则二，通过合并特性分支，形成发布分支。
AoneFlow 的发布分支设计十分巧妙，可谓整个体系的精髓。GitFlow 先将已经完成的特性分支合并回公共主线（即开发分支），然后从公共主线拉出发布分支。TrunkBased 同样是等所有需要的特性都在主干分支上开发完成，然后从主干分支的特定位置拉出发布分支。而 AoneFlow 的思路是，从主干上拉出一条新分支，将所有本次要集成或发布的特性分支依次合并过去，从而得到发布分支。发布分支通常以release/前缀命名。
这条规则很简单，不过实际的玩法就相当丰富了。
首先，发布分支的用途可以很灵活。基础玩法是将每条发布分支与具体的环境相对应，比如release/test分支对应部署测试环境，release/prod分支对应线上正式环境等等，并与流水线工具相结合，串联各个环境上的代码质量扫描和自动化测试关卡，将产出的部署包直接发布到相应环境上。进阶点的玩法是将一个发布分支对应多个环境，比如把灰度发布和正式发布串在一起，中间加上人工验收的步骤。高级的玩法呢，要是按迭代计划来关联特性分支，创建出以迭代演进的固定发布分支，再把一系列环境都串在这个发布分支的流水线上，就有点经典持续集成流水线的味道了。再或者做一个将所有特性分支都关联在一起的发布分支，专门用于对所有提交做集成测试，就玩出了 TrunkBased 的效果。当然，这些花哨的高级玩法是我臆想的，阿里的发布分支一般都还是比较中规中矩。
其次，发布分支的特性组成是动态的，调整起来特别容易。在一些市场瞬息万变的互联网企业，以及采用“敏捷运作”的乙方企业经常会遇到这种情况，已经完成就等待上线的需求，随时可能由于市场策略调整或者甲方的一个临时决定，其中某个功能忽然要求延迟发布或者干脆不要了。再或者是某个特性在上线前发现存在严重的开发问题，需要排除。按往常的做法，这时候就要来手工“剔代码”了，将已经合并到开发分支或者主干分支的相关提交一个个剔除出去，做过的同学都知道很麻烦。在 AoneFlow 的模式下，重建发布分支只是分分钟的事，将原本的发布分支删掉，从主干拉出新的同名发布分支，再把需要保留的各特性分支合并过来就搞定。这一系列动作能够在很大程度上实现自动化，而且不会在仓库留下一堆剔除代码的记录，干净无污染。
此外，发布分支之间是松耦合的，这样就可以有多个集成环境分别进行不同的特性组合的集成测试，也能方便的管理各个特性进入到不同环境上部署的时机。松耦合并不代表没有相关性，由于测试环境、集成环境、预发布环境、灰度环境和线上正式环境等发布流程通常是顺序进行的，在流程上可以要求只有通过前一环境验证的特性，才能传递到下一个环境做部署，形成漏斗形的特性发布流。阿里有统一平台来自动化完成特性组合在发布分支间的迁移，在下面讲工具的部分里会再介绍。
规则三，发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。
当一条发布分支上的流水线完成了一次线上正式环境的部署，就意味着相应的功能真正的发布了，此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支，还应该清理掉已经上线部分特性分支。与 GitFlow 相似，主干分支上的最新版本始终与线上版本一致，如果要回溯历史版本，只需在主干分支上找到相应的版本标签即可。
除了基本规则，还有一些实际操作中不成文的技巧。比如上线后的 Hotfix，正常的处理方法应该是，创建一条新的发布分支，对应线上环境（相当于 Hotfix 分支），同时为这个分支创建临时流水线，以保障必要的发布前检查和冒烟测试能够自动执行。但其实还有一种简便方法是，将线上正式环境对应的发布分支上关联的特性分支全部清退掉，在这个发布分支上直接进行修改，改完利用现成的流水线自动发布。如果非得修一个历史版本的 Bug 怎么办呢？那就老老实实的在主干分支找到版本标签位置，然后从那个位置创建 Hotfix 分支吧，不过由于阿里的产品大多是线上 SaaS 业务，这样的场景并不多见。
正是这些简单的规则，组成了 AoneFlow 独树一帜的核心套路。
AoneFlow 中每一个看似简单的步骤都并非凭空臆造，而是经历大量产品团队反复磨砺后积累下来的经验。接下来，我会说说 AoneFlow 的技术门槛以及阿里内部的应对之道。
思考总结，目前使用AoneFlow
总结下就是各种git工作流都是 功能分支 + 长期分支 构成。
目前公司使用的协同工作流是基于AoneFlow而来，也有些GitFlow的身影。也符合AoneFlow的三个规则：
开始工作前，从主干创建特性分支
通过合并特性分支，形成发布分支
发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支
有如下分支：
master分支：（长期存在）master分支上的代码一定是已经发到生产环境的代码，可能会稍有延迟（发到release分支的代码不一定马上合到master）。
test分支：（长期存在）相当于gitFlow中的develope分支，是集成测试环境分支，会包含各种开发中的功能。
pre_prod分支：（长期存在）预发环境分支，在线上生产环境代码的基础上加上本次需要发布的内容。
release/master分支：（长期存在）线上生产环境分支。
release/canary分支：（长期存在）灰度环境分支
feature/feature01分支：功能分支，在发布后可以删除。
hotfix分支：线上bug修复分支，其实和feature分支操作一样，也是从master分支新建出来。
开发到发布的过程如下：
从master分支新建一个分支feature001；
开发一部分后或者开发完后feature合到test分支，如果提测了测试会在这个分支先测试；
测试完成如果有预发环境会发布到预发环境；
预发通过后会合并到发布分支release/v1.1分支，可能是多个feature分支都合过来；
release/v1.1分支合并到release/master分支，至此就发布到线上环境了。
如果发布完后没有问题，release/master会合并会master（一般不会合并完成就马上合，万一要撤回呢-_-，个人习惯在每次新建feature分支的时候检查下release/master是否比master新， 如果新的话就会合并回master分支）
bug修复，在master分支新建hotfix/hotfix001,改完后合并到test分支，测试后合并到最新的release/v1.1分支上，或者新建release/v1.1_bugfix001分支， 然后再合并到release/master分支。 最后release/master合回master。
如果发布后有问题需要撤回怎么办？
把release/master 回退到上次发布时间点的代码，重新发布。
如果多个featuer分支同时开发，但是一个分支对另一个分支有依赖关系怎么办？
根据计划发布顺序来，如果feature1会先于feature2发布， 那feature2分支就从master新建然后把featuer1合并过来，尽量定期同步，可以避免很多的冲突，等feature1发布完合会master后，再把master分支合并到feature2分支。这样可以确保feature2分支上是在线上环境代码的基础只有feature2的改动。
协同工作流的本质
此部分摘自陈皓的文章，觉得另辟蹊径，是更深层次的思考，原文如下：
代码的协同工作流属于 SCM（Software Configuration Management）的范畴，要挑选好适合自己的方式，我们需要知道软件工程配置管理的本质。
根据这么多年来我在各个公司的经历，有互联网的，有金融的，有项目的，有快速迭代的等，我认为团队协同工作的本质不外乎这么几个事儿。
不同的团队能够尽可能地并行开发。
不同软件版本和代码的一致性。
不同环境和代码的一致性。
代码总是会在稳定和不稳定间交替。我们希望生产线上的代码总是能对应到稳定的代码上来。
基本上述的四个事儿，上述的工作流大都是在以建立不同的分支，来做到开发并行、代码和环境版本一致，以及稳定的代码。
要选择适合自己的协同工作流，我们就不得不谈一下软件开发的工作模式。
首先，我们知道软件开发的趋势一定是下面这个样子的。
以微服务或是 SOA 为架构的方式。一个大型软件会被拆分成若干个服务，那么，我们的代码应该也会跟着服务拆解成若干个代码仓库。这样一来，我们的每个代码仓库都会变小，于是我们的协同工作流程就会变简单。对于每个服务的代码仓库，我们的开发和迭代速度也会变得很快，开发团队也会跟服务一样被拆分成多个小团队。这样一来， GitFlow 这种协同工作流程就非常重了，而 GitHub 这种方式或是功能分支这种方式会更适合我们的开发。
以 DevOps 为主的开发流程。DevOps 关注于 CI/CD，需要我们有自动化的集成测试和持续部署的工具。这样一来，我们的代码发布速度就会大大加快，每一次提交都能很快地被完整地集成测试，并很快地发布到生产线上。
于是，我们就可以使用更简单的协同工作流程，不需要维护多个版本，也不需要关注不同的运行环境，只需要一套代码，就可以了。GitHub Flow 或是功能分支这种方式也更适应这种开发。
你看，如果我们将软件开发升级并简化到 SOA 服务化以及 DevOps 上来，那么协同工作流就会变得非常简单。所以，协同工作流的本质，并不是怎么玩好代码仓库的分支策略，而是玩好我们的软件架构和软件开发流程。
当然，服务化和 DevOps 是每个开发团队需要去努力的目标，但就算是这样，也有某些情况我们需要用重的协同工作的模式。比如，整个公司在做一个大的升级项目，这其中会对代码做一个大的调整（很有可能是一次重大的重构）。
这个时候，可能还有一些并行的开发需要做，如一些小功能的优化，一些线上 Bug 的处理，我们可能还需要在生产线上做新旧两个版本的 A/B 测试。在这样的情况下，我们可能会或多或少地使用 GitFlow 协同工作流。
但是，这样的方式不会是常态，是特殊时期，我们不可能隔三差五地对系统做架构或是对代码做大规模的重构。所以，在大多数情况下，我们还是应该选择一个比较轻量的协同工作流，而在特殊时期特例特办。
与其花时间在 Git 协同工作流上，还不如把时间花在调整软件架构和自动化软件生产和运维流程上来，这才是真正简化协同工作流程的根本。
参考文章
陈皓 的《左耳听风 》- Git协同工作流，你该怎么选
