原文链接： Git 分支办理战略
最近，团队新入职了一些小伙伴，在开发过程中，他们问我 Git 分支是怎样办理的，以及应该怎样提交代码？
我大概说了一些规则，但仔细想来，如同也并没有形成一个明晰标准的流程。所以查了一些资料，总结出下面这篇文章，一共包含四种常见的分支办理战略，分享给大家。
Git flow
在这种模式下，首要维护了两类分支：
- 首要分支 (The main branch)
- master
- develop
- 辅助分支 (Supporting branch)
- feature branch (功用分支)
- release branch (预发布分支)
- hotfix branch (热修正分支)
master
首要，代码库应该有一个、且仅有一个主分支。master 分支的代码永远是安稳的，能够随时发布到出产环境。
develop
develop 分支用于日常开发，保存了开发过程中最新的代码。
当 develop 分支上的代码到达安稳，而且具备发版状态时，需求将 develop 的代码兼并到 master，而且打一个带有发布版别号的 tag。
创立 develop 分支：
git checkout -b develop master
将 develop 兼并到 master：
# 切换到 master 分支
git checkout master
# 对 develop 分支进行兼并
git merge --no-ff develop
--no-ff 参数的作用是使当时的兼并操作总是创立一个新的 commit 目标，即便该兼并被执行为快进式（fast-forward）兼并。
这样能够防止丢失掉该功用分支的历史信息，而且将针对该功用的一切提交都集中到一同。这样解释也并不是很易懂，通过下图来比照一下就比较显着了：
feature
- 分支来历：develop
- 兼并到分支：develop
- 分支命名约好：feature-*
功用分支，在开发某一个新功用时，从 develop 分支分出来，开发完之后，再兼并回 develop 分支。
功用分支一般只存在于开发者的本地库房中，并不包含在长途库中。
创立一个功用分支：
git checkout -b feature-x develop
开发完成后，将功用分支兼并到 develop 分支：
git checkout develop
git merge --no-ff feature-x
删去 feature 分支：
git branch -d feature-x
release
- 分支来历：develop
- 兼并到分支：develop，master
- 分支命名约好：release-*
预发布分支，它是指发布正式版别之前，咱们或许需求有一个预发布的版别测验，而且能够在上面做一些较小 bug 的修正。
预发布分支是从 develop 分支上分出来的，预发布完毕以后，有必要兼并进 develop 和 master 分支。
创立一个预发布分支：
git checkout -b release-1.2 develop
承认没有问题后，兼并到 master 分支：
git checkout master
git merge --no-ff release-1.2
# 对兼并生成的新节点，做一个标签
git tag -a 1.2
再兼并到 develop 分支：
git checkout develop
git merge --no-ff release-1.2
最终，删去预发布分支：
git branch -d release-1.2
hotfix
- 分支来历：master
- 兼并到分支：develop，master
- 分支命名约好：hotfix-*
最终一种是修正 bug 分支。软件正式发布以后，难免会呈现 bug。这时就需求创立一个分支，进行 bug 修正。
修正 bug 分支是从 master 分支上分出来的。修正完毕以后，再兼并进 master 和 develop 分支。
创立一个修正 bug 分支：
git checkout -b hotfix-0.1 master
修正完毕后，兼并到 master 分支：
git checkout master
git merge --no-ff hotfix-0.1
git tag -a 0.1.1
再兼并到 develop 分支：
git checkout develop
git merge --no-ff hotfix-0.1
最终，删去修正 bug 分支：
git branch -d hotfix-0.1
小结
长处：
- 各分支权责分明，明晰可控，是许多分支办理战略的启蒙模型。
缺陷：
- 兼并抵触：同时长时间存在的分支或许会许多：master、develop、release、hotfix、若干并行的 feature 分支。两两之间都有或许发生抵触。频频手动处理抵触不只增加作业量，而且增大了出错的危险。
- 功用分离：功用并行开发时，兼并分支前无法测验组合功用，而且兼并后或许会呈现相互影响。
- 无法继续交给：Git flow 更倾向于按方案发布，一个 feature 要阅历许多过程才干发布到正式环境，难以到达继续交给的要求。
- 无法继续集成：继续集成鼓励更加频频的代码集成和交互，尽早处理抵触，而 Git flow 的分支战略隔离了代码，尽或许推延代码集成。
Github flow
Github 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 分红两种景象来应付不同的开发流程：
- 继续发布
- 版别发布
继续发布
对于继续发布的项目，它主张在 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 分支，而且此刻要更新小版别号。
小结
长处：
- 能够区分不同的环境布置。
- 对继续交给和继续集成友好。
缺陷：
- 分支多，流程办理复杂。
TrunkBased
Trunk Based Development，又名骨干开发。开发人员之间通过约好，向被指定为骨干，一般为 master，的分支提交代码，以此来反抗因为长时间存在的多分支导致的开发压力。这样能够防止分支兼并的困扰，确保随时具有可发布的版别。
运用骨干开发后，只要一个 master 分支了，一切新功用也都提交到 master 分支上，确保每次提交后 master 分支都是可随时发布的状态。
没有了分支的代码隔离，测验和处理抵触都变得简略，继续集成也变得安稳了许多，但也有如下几个问题：
- 怎样防止发布的时分引入未完成的 feature
- 怎样进行线上 bug fix
怎样防止发布的时分引入未完成的 feature
答案是：Feature Toggle。
既然代码要随时保持可发布，而咱们又需求只要一份代码来支撑继续集成，在代码库里加一个特性开关来随时翻开和关闭新特性是最容易想到的，当然也是最容易被质疑的处理方案。
Feature Toggle 是有成本的，不管是在加 Toggle 的时分的代码规划，仍是在移除 Toggle 时的人力成本和危险，都是需求和它带来的价值进行衡量的。
事实上，在咱们做一个前端的大特性改变的时分，咱们确实因为没办法 Toggle 而采用了一个独立的 feature 分支，咱们认为即便为了这个分支独自做一套 Pipeline，也比在前端的各种款式间添加移除 Toggle 来得简略。
但同时，团队协商决定在每次提交前都要先将 master 分支兼并到 feature 分支，以此防止分支隔离久以后兼并时的苦楚。
怎样进行线上 bug fix
在发布时打上 release tag，一旦发现这个版别有问题，假如这个时分 master 分支上没有其他提交，能够直接在 master 分支上 hot fix，假如 master 分支已经有了提交就要做以下四件事：
- 从 release tag 创立发布分支。
- 在 master 上做 bug fix 提交。
- 将 bug fix 提交 cherry-pick 到 release 分支。
- 在 release 分支再做一次发布。
线上 fix 一般都比较紧迫。看完这个略显繁琐的 bug fix 流程，你或许会问为什么不在 release 分支直接 fix，再兼并到 master 分支？
这样做确实比较符合直觉，但事实是，假如在 release 分支做 fix，很或许会忘了兼并回 master。
试想深夜两点你做完 bug fix 眼看总算上线成功，这时你的榜首反应便是“总算能够下班了。什么，兼并回 master？ 明日再来吧“
等到第二天你早已把这个事忘得一尘不染。而问题要等到下一次上线才会被暴露出来，一旦发现，而这个时分上一次 release 的人又不在，无疑增加了许多作业量。
总结
以上四种便是目前相对干流的分支办理战略，但没有哪一种战略是全能的。所以不管选择哪一种，都需求考虑团队的实际情况，以及项目的具体事务需求，适合自己的才是最好的。
最终，再分享三点小主张：
- 临时分支不应该存在太久，每个分支应尽量保持精简，用完即删
- 作业流应该尽量简略，同时便利回滚
- 作业流程应该符合咱们的项目发布方案
以上便是本文的全部内容，假如觉得还不错的话欢迎点赞，转发和重视，感谢支撑。
参阅文章：
- Git 分支办理战略与作业流程
- Git 分支办理战略总结
- 一个完美的 Git 分支办理模型
- Git 作业流程
- Git 分支办理战略
- 分支模型与骨干开发
扩展阅读：
- 在阿里，咱们怎样办理代码分支？
- 谷歌的代码办理
推荐阅读：
