Git 分支管理策略总结

1 基础知识：Git 分支类型

git官方文档中，将分支分为了两大类，后续介绍的分支管理策略都是基于这个分类进行拓展的。html

1.1 长期分支

在整个项目开发周期的不一样阶段，按期把某些主题分支合并入其余长期分支中。这些长期分支大概分为三种类型：git

（1）分支上的代码达到稳定状态，多是已经发布了的或即将要发布。例如master分支。github

（2）还有一些名为develop或next的平行分支，用来作后续开发或测试稳定性，当这些分支达到稳定状态就能够合并入master分支。web

（3）还有一些proposed分支，可能包含一些不成熟的内容，当他们具备必定程度的稳定性后，再合并入更高稳定性的分支。shell

稳定性越高的分支，在代码提交历史中指针越靠后： bash

1.2 主题分支

主题分支是一种短时间分支，用来实现单一特性或其相关工做。可能会被频繁建立、使用、合并、删除。这样有利于快速而且完整地进行上下文切换，将工做分散到不一样的流水线中，每一个流水线的分支都仅与其目标特性相关，在作代码审查的时候能更加容易地看出你作了哪些改动。markdown

2 git-flow model

git-flow模型是Vincent Driessen在2010年提出的经典模型。他将分支分为了几种不一样类型，每种类型都有明确的职责。并发

2.1 主要分支（The main branches）

有两个常驻分支：master和develop。ide

master分支中的最新代码永远都是能够发布到生产环境的稳定状态。oop

develop分支中的最新代码永远反映了最新的变化，为下一次发布作准备。有些人也把这个分支叫作集成分（integration branch），这是构建任何夜间自动构建的地方。

当develop分支中的代码达到稳定状态并准备发布时，须要合并到master，而后打上tag来标记发布的版本号。所以，每次变化合并进master分支时，也就是新版本发布的时候。

2.2 支持分支（Supporting branches）

支持分支的生命周期较短，而且最终会被删除。主要用来帮助团队成员之间进行并行开发，简化功能跟踪，为产品发布作准备并协助快速解决生产中的实际问题。

一般使用三种类型的支持分支：

功能分支（Feature branches）
发布分支（Release branches）
修补程序分支（Hotfix branches）

这些分支中的每个都有特定的用途，并受严格的规则约束。这些分支并无技术层面上的差异，只是根据咱们的使用方式进行了分类。

2.3 Feature branches (topic branches)

分支来源：develop
合并到分支：develop
分支命名约定：除了master, develop, release-*, 或 hotfix-*的任意名字。

feature分支一般用来开发新的feature，最终会合并回到develop分支中或废弃掉。

功能分支一般仅存在于开发人员的本地仓库中，而不存在于origin中。

建立一个feature分支： $ git checkout -b myfeature develop

feature分支开发完成后须要合并回develop分支：

$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
复制代码

--no-ff会建立一个合并的commit，来记录这一次的合并分支信息；若是不加该参数，合并分支的时候不会再有合并的commit。

2.4 Release branches

分支来源：develop
合并到分支：develop 和 master
分支命名约定：release-*

release分支为一次新的版本发布作准备，这个阶段主要进行最后的检查、小的bug修复，并为发布准备元数据(版本号、构建日期等)。

当develop分支近乎达到了新版本发布的指望状态，就能够从中建立一个新的release分支了，此时全部新版本要发布的功能都已经合并进develop。其余将来发布版本的功能必须等到这次release分支建立后，才能够合并进develop分支。

建立release分支时，肯定了即将发布的版本号。例如当前版本是1.1.5，假以下一次是比较大的版本发布，因此release分支能够命名为release-1.2。

$ git checkout -b release-1.2 develop
$ ./bump-version.sh 1.2
$ git commit -a -m "Bumped version number to 1.2"
复制代码

当建立完release分支时，咱们升级了版本号。在这里，bump-version.sh是一个虚构的shell脚本，它更改工做副本中的一些文件以反映新版本。(固然，也能够手动更改)而后，提交升级后的版本号。

这个新分支会一直存在，直到最终发布，在此期间只容许bug修复，禁止添加大的新功能。当release分支的状态达到能够发布的程度时，就合并进master分支。而后在master分支上的commit打上tag，来记录版本号，方便未来回滚或追溯。最后，release分支上的改动还要合并回develop分支。在合并回develop分支的时候可能会出现冲突，由于develop分支可能合并了一些新的feature，这时须要解决冲突并提交。

$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2

$ git checkout develop
$ git merge --no-ff release-1.2
复制代码

在打tag的时候还可使用-s或-u 标志来对tag进行加密签名。

最后能够删除这个release分支了。

$ git branch -d release-1.2
复制代码

2.5 Hotfix branches

分支来源：master
合并到分支：develop 和 master
分支命名约定：hotfix-*

当生产版本出现了一个严重的bug必需要马上修复时，能够从当前master分支上建立一个hotfix分支来修复bug。

例如当前版本号为1.2的生产环境中出现了一个严重的bug急需修复，能够建立一个hotfix-1.2.1分支。

$ git checkout -b hotfix-1.2.1 master
$ ./bump-version.sh 1.2.1
$ git commit -a -m "Bumped version number to 1.2.1"
复制代码

git commit -a -m 合并了 git add 和 git commit 两个步骤。

修复bug并提交：

$ git commit -m "Fixed severe production problem"
复制代码

修复完，这些bugfix须要合并进master，同时还须要合并回develop。

$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1

$ git checkout develop
$ git merge --no-ff hotfix-1.2.1
复制代码

若是这时还有一个release分支同时存在，那么hotfix分支就不须要合并回develop分支，而是合并到release分支，由于release分支最终仍是回合并回develop分支。但若是这个bug会影响到develop分支上的开发，则能够合并到develop分支。

最后，删除hotfix分支。

$ git branch -d hotfix-1.2.1
复制代码

2.6 评价

做者在2020年3月5日对该模型又作了一些说明：因为gitflow-model更适合多个版本并存的场景，但现现在的web应用不多会须要多版本并存，更多的是一个版本持续交付，所以推荐使用更简单的模型，例如GitHub flow。

优势：各分支权责分明，清晰可控，是不少分支管理策略的启蒙模型。

缺点：

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

3 GitHub flow

GitHub flow是一个轻量级的、基于分支的工做流。是 Github 使用的工做流程。它只保留一个主分支master，开发新功能时基于master建立一个feature分支，开发完成后发起Pull-Request。小组内进行讨论和评审，并及时反馈，开发者在此期间能够不断提交代码。评审经过后再合并回master分支，并进行部署。

3.1 评价

优势：

分支简单，只有master主分支，和feature分支，下降了分支管理的复杂度。
符合持续集成：尽早反馈、有问题尽早解决，集成周期短。

缺点：master分支发布前，其余代码没法提交，不然master分支就会与刚发布的版本不一致。

4 Gitlab flow

吸收了Git flow 与 Github flow和优势，Gitlab推荐的作法，具体可见阮一峰老师的这篇文章，此处再也不赘述。

5 Trunk based Development 主干开发

存在一个分支做为主干分支，即master分支，开发人员直接向主干分支提交代码，或将feature分支只留在本地。原则上，代码仓库就只有一个master分支了。开发团队成员能够一天内屡次将代码提交到主干分支，使团队的工做在24小时内就能够被整合，保证了代码版本随时处于可发布的状态。避免长期存在多个分支，有利于持续集成和持续交付。

发布时直接从主干分支上建立release分支，并打上tag，发布完成后删除release分支。换句话说，发布分支是主干分支某个时点的快照。

主干开发要求每次提交都是一个可上线的版本，所以也带来了一些问题，下面给出相应的解决方案：

如何避免发布未完成的feature：使用Feature Toggle —— 在代码中增长一个特性开关来控制新特性的打开与关闭。
如何修复线上bug：发布时打tag，若是这个版本出现问题，若是master分支没有新的提交，就直接在master分支上修复，而后合并到release分支；若是master分支已经有新提交了则：

从tag处建立release分支
在master上修复bug
将修复bug的提交cherry pick到release分支
在release分支上打tag并发布

6 AoneFlow

AoneFlow是阿里内部使用的代码分支管理策略，“它基本上兼顾了 TrunkBased 的‘易于持续集成’和 GitFlow 的‘易于管理需求’特色，同时规避掉 GitFlow 的那些繁文缛节”。

AoneFlow 只使用三种分支类型：主干分支、特性分支、发布分支。一个完整的流程以下：

从主干上建立一个特性分支（前缀为feature/），而后在这个分支上进行代码开发。可能会有多个特性分支并行开发。

从主干上建立一个发布分支（前缀为release/），将全部要发布的特性分支合并到发布分支上。发布分支能够有多个，分别对应不一样的环境，如release/test分支对应部署测试环境，release/prod分支对应线上正式环境等等。也能够一个发布分支对应多个环境。发布分支的特性组成是动态的，例如某个功能或特性由于某些缘由没法如期发布，能够删除这个分支，再从主干重建一个同名发布分支，只把须要发布的特性分支合并过来。发布分支之间松耦合，能够将不一样的特性组合发布到不一样的环境中。

发布分支发布到线上后再合并回主干分支，并在主干分支打上标签，最后删除与该发布分支关联的特性分支。