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

修复 bug 分支是从 master 分支上分出来的。修复结束以后，再合并进 master 和 develop 分支。
创建一个修复 bug 分支：
git checkout -b hotfix-0.1 master修复结束后，合并到 master 分支：
git checkout mastergit merge --no-ff hotfix-0.1git tag -a 0.1.1再合并到 develop 分支：
git checkout developgit merge --no-ff hotfix-0.1最后，删除修复 bug 分支：
git branch -d hotfix-0.1小结优点：

各分支权责分明，清晰可控，是很多分支管理策略的启蒙模型。

缺点：

合并冲突：同时长期存在的分支可能会很多：master、develop、release、hotfix、若干并行的 feature 分支。两两之间都有可能发生冲突。频繁手动解决冲突不仅增加工作量，而且增大了出错的风险。
功能分离：功能并行开发时，合并分支前无法测试组合功能，而且合并后可能会出现互相影响。
无法持续交付：Git flow 更倾向于按计划发布，一个 feature 要经历很多步骤才能发布到正式环境，难以达到持续交付的要求。
无法持续集成：持续集成鼓励更加频繁的代码集成和交互，尽早解决冲突，而 Git flow 的分支策略隔离了代码，尽可能推迟代码集成。

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

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

小结：优点：

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

缺点：

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

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