git协同工作流，你们公司使用哪一种呢

1 Trunk Based Development

Trunk Based Development（TBD）早在svn时代就已经流行，是种比较简单的分支管理模型。

典型的TBD模型如下：

特点：

• 他只有一个主干分支
• 每个人写完代码自测通过后就往主干上面Push，要发布的时候就拉个Release分支。

优点：

• 对持续集成友好。

缺点：

• 多个人开发多个功能时代码干扰比较严重；

• 如果临上线前发现有问题，剔除代码比较困难；
• 即使没有需求变更要下掉代码，有些提交如果未能达到上线标准，需要加Feature Toggle来控制打开关闭。这是一个需要平衡的事情，往往会增加一定开发成本和风险；

适用：

• 因相对简单，难以应对复杂情况，适用用于小型项目

2 功能分支协同工作流

上面的那种方式有一个问题，就是大家都在一个主干上开发程序，对于小团队或是小项目你可以这么干，但是对比较大的项目或是人比较多的团队，这么干就会有很多问题。

最大的问题就是代码可能干扰太严重。尤其是，我们想安安静静地开发一个功能时，我们想把各个功能的代码变动隔离开来，同时各个功能又会有多个开发人员在开发。

这时，我们不想让各个功能的开发人员都在 Master 分支上共享他们的代码。我们想要的协同方式是这样的：同时开发一个功能的开发人员可以分享各自的代码，但是不会把代码分享给开发其他功能的开发人员，直到整个功能开发完毕后，才会分享给其他的开发人员（也就是进入主干分支）。

因此，我们引入“功能分支”，如下：

就像上面这个图显示的一样，紫色的分支就是功能分支，合并后就会像上面这个样子。

3 GitFlow 协同工作流

在真实的生产过程中，前面的协同工作流还是不能满足工作的要求。这主要因为我们的生产过程是比较复杂的，软件生产中会有各式各样的问题，并要面对不同的环境。我们要在不停地开发新代码的同时，维护线上的代码，于是，就有了下面这些需求。

1. 希望有一个分支是非常干净的，上面是可以发布的代码，上面的改动永远都是可以发布到生产环境中的。这个分支上不能有中间开发过程中不可以上生产线的代码提交。
2. 希望当代码达到可以上线的状态时，也就是在 alpha/beta release 时，在测试和交付的过程中，依然可以开发下一个版本的代码。

1. 最后，对于已经发布的代码，也会有一些 Bug-fix 的改动，不会将正在开发的代码提交到生产线上去。

你看，面对这些需求，前面的那些协同方式就都不行了。因为我们不仅是要在整个团队中共享代码，我们要的更是管理好不同环境下的代码不互相干扰。说得技术一点儿就是，要管理好代码与环境的一致性。

为了解决这些问题，GitFlow 协同工作流就出来了。

GitFlow 协同工作流是由 Vincent Driessen 于 2010 年在 A successful Git branching model 这篇文章介绍给世人的。

这个协同工作流的核心思想如下图所示。

整个代码库中一共有五种分支。

• Master 分支。也就是主干分支，用作发布环境，上面的每一次提交都是可以发布的。
• Feature 分支。也就是功能分支，用于开发功能，其对应的是开发环境。

• Developer 分支。是开发分支，一旦功能开发完成，就向 Developer 分支合并，合并完成后，删除功能分支。这个分支对应的是集成测试环境。
• Release 分支。当 Develo