Git 分支管理策略汇总( 二 ) _生活百科

合并冲突：同时长期存在的分支可能会很多：master、develop、release、hotfix、若干并行的 feature 分支。两两之间都有可能发生冲突。频繁手动解决冲突不仅增加工作量，而且增大了出错的风险。

功能分离：功能并行开发时，合并分支前无法测试组合功能，而且合并后可能会出现互相影响。

无法持续交付：Git flow 更倾向于按计划发布，一个 feature 要经历很多步骤才能发布到正式环境，难以达到持续交付的要求。

无法持续集成：持续集成鼓励更加频繁的代码集成和交互，尽早解决冲突，而 Git flow 的分支策略隔离了代码，尽可能推迟代码集成。

Github flowGithub flow 是一个轻量级的基于分支的工作流程。它由 GitHub 在 2011 年创建。分支是 Git 中的核心概念，并且 GitHub 工作流程中的一切都以此为基础。
它只有一个长期分支 master，其他分支都在其基础上创建。使用流程如下：

根据需求，从 master 拉出新分支，不用区分功能分支或修复分支，但需要给出描述性的名称。
本地的修改直接提交到该分支，并定期将其推送到远程库上的同一命名分支。
新分支开发完成后，或者需要讨论的时候，向 master 发起一个 Pull Request（简称 PR）。
【Git 分支管理策略汇总】Pull Request 既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
你的 Pull Request 被接受，合并进 master，重新部署后，原来你拉出来的那个分支就被删除了。

小结：优点：

降低了分支管理复杂度，更适合小型团队，或者维护单个版本的项目开发。
工作流程简单，对持续交付和持续集成友好。

缺点：

无法支持多版本代码部署。

Gitlab flow它是 Git flow 与 Github flow 的综合。吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。
Gitlab flow 和 Github flow 之间的最大区别是 Gitlab flow 支持环境分支。
Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支 master，它是所有其他分支的"上游" 。只有上游分支采纳的代码变化，才能应用到其他分支。
Gitlab flow 分成两种情形来应付不同的开发流程：

持续发布
版本发布

持续发布对于持续发布的项目，它建议在 master 分支以外，再建立不同的环境分支，每个环境都有对应的分支。比如，开发环境的分支是 master，预发环境的分支是 pre-production，生产环境的分支是 production 。

开发分支 master 用于发布到测试环境，该分支为受保护的分支。
预发分支 pre-production 用于发布到预发环境，上游分支为 master 。
正式分支 production 用于发布到正式环境，上游分支为 pre-production 。

如果生产环境（production）发生错误，则要建一个新分支修改完后合并到最上游的开发分支（master）此时就是（Upstream first），且经过测试，再继续往 pre-production 合并，要经过测试没有问题了才能够再往下合并到生产环境。
版本发布对于版本发布的项目，建议的做法是每一个稳定版本，都要从 master 分支拉出一个分支，比如 2-3-stable、2-4-stable 等。
在出现 bug 后，根据对应的 release branch 创建一个修复分支，修复工作完成后，一样要按照上游优选的原则，先合并到 master 分支，经过测试才能够合并到 release 分支，并且此时要更新小版本号。
小结优点：

可以区分不同的环境部署。
对持续交付和持续集成友好。

缺点：

分支多，流程管理复杂。

TrunkBasedTrunk Based Development，又叫主干开发。开发人员之间通过约定，向被指定为主干，一般为 master，的分支提交代码，以此来抵抗因为长期存在的多分支导致的开发压力。这样可以避免分支合并的困扰，保证随时拥有可发布的版本。
使用主干开发后，只有一个 master 分支了，所有新功能也都提交到 master 分支上，保证每次提交后 master 分支都是可随时发布的状态。