Android 实战项目（3）——Git 分支管理模型

首发公众号：Android程序员日记

作者：贤榆的榆

如果你觉得有帮助欢迎关注、赞赏、转发

阅读时间：5622字 15分钟

通常当我们在进行一个正式项目的时候，一定的分支管理是必要，这里推荐大家阅读两篇文章，我自己也是从这两篇文章中受益匪浅。

第一篇是国外行家Vincent Driessen 的《A successful Git branching model》

地址：https://nvie.com/posts/a-successful-git-branching-model/

第二篇阮一峰老师的《Git分支管理策略》

地址：http://www.ruanyifeng.com/blog/2012/07/git.html

好了，那么接下来，我就站在前人的肩膀上结合这自己的实践，来简单介绍一下上面两篇文章中提到的分支管理策略吧。我们先来看一张图哪位外国哥们的图。

小声声明：这部分几乎所有的图片都引用自《A successful Git branching model》这篇博客。

git分支管理模型图

看图的最上面，出现了feture branches、develop、release branches、hotfixes、master。看似总共五种分支，但其实这其中归纳一下只有两种：

一种是主要分支

一种是临时分支

主要分支

那么我们先来说一下主要分支。从上面的图里，其实我们也不难看出来，develop和master 是两个主干分支。与临时分支的唯一区别时，他们包含了所以其他临时分支的提交。

1、master分支

在主要分支中，master是在我们运行git init 之后就会默认生成的分支，所以我们的其他所以分支的起点应该都是从master分支check出去的。另外我们通常也正是用这个master分支也用来记录我们的每一个生产版本，所以每一次合并其他分支到mater分支时，都应该非常的谨慎。

2、devleop分支

在主要分支中，develop是我们的开发分支，是从master 切出来的。而最终当我们开发完成之后，我们都一定会将其合并回master，然后打出一个生产包，在用tag标记一个版本的发行。master与develop分支的关系图如下：

有一个git 命令可以学一下

将本地develop分支推送至远端仓库，如果远端没有develop会自动创建！

临时分支

主要分支说完了，那我们聊一聊临时分支吧。在Vincent Driessen的那篇文章中，称之为Supporting branches（支持分支）。其实都是一样的了，他按照分支的作用来归类命名。我是根据分支的生命周期的角度给了此命名。通过对这组分支的命名大家应该都已经了解到了。临时分具有一定的实效行，它往往承载的是一段时间里的一件独立的事。所以这里我们通常分出了三种：

feature（功能分支）

hotfix（bug修复分支）

release-（发布版分支）

1、feature（功能分支）

先说说功能分支吧。通常我们从develop分支上切出一个新的分支来开发一个新的功能，并且我们通常以该功能命名。比如在我最近的一个项目中做了一个消息通知的功能，于是我切了一个新的分支叫inform。最后当我们将该功能开发完之后仍会将其合并到devleop分支。当然如果只有一个人那似乎用不用功能分支都不重要。所以分支管理最重要的是进行更好的团队协作，达到到敏捷迭代，高效开发，在技术层面快速占领市场。下面是feature与devleop的关系图，注意这里的branches是复数，哈哈，细节很重要：

介绍一下在这个过程中可能会用的git指令。

在开发过程中会用到的：

在功能分支开发完成之后会用到的：

这里merge 后面跟了--no-ff ，加不加它有什么区别呢，我们现在这里卖个关子，在文章最后，会进行补充说明。

2、release（预发布分支）

release是一个预发布分支。在一个迭代中，当我们完成了一个或者几个小功能之后，我们会把feature 分支们都合并到develop分支上，这时develop分支其实就可以作为一个预发布分支了。但是如果还有其他小伙伴正在开发下一个迭代发布的功能。那么极有可能出现一种情况，就是他在功能分支上面开发完成了，却无法合并到develop分支上，因为此时的develop分支已经同时承载了预发布阶段的性能优化、bug修复并等代发布上线等任务，是不能够合并其他分支的代码的。所以这个时候我们就非常需要从develop分支牵出一个新的分支来作为完成我们预发布阶段的相关功能。而这就是我们的release分支了。所以release分支也会在这期间将修复后的代码频繁的合并到develop分支上。（如上图，该图没有现成的，所以是在大师原有的keynote上修改出来的）我们在开发过程中，通常以当天下午下班前十分钟为节点，合并当日修复的代码到develop分支！

另外要说的就是release分支的命名了，通常我们已即将发布的版本号为后缀添加到release-后面，例如：release-2.0.0、release-2.2.2等等。

介绍一下release分支生命周期中可能会用的git指令流程。

3、hotfix（bug修复分支）

最后我们来了解一下bug修复分支，这个翻译过来就是热修复分支。估计是想强调线上bug修复，我们需要开分支来进行修复线上bug的。其实bug修复分支和上面讲到的预发布分支几乎是一个类型的。不同的地方无非是，bug修复分支是在发布后修复线上bug，所以要从已经发布的master分支上牵出hotfix分支。而release分支是在发布之前来进行bug修复，所以从develop分支钱出来。但他们最终合并的时候都是要合并到master再合并到develop分支的。而最后，他们在完成了各自的使命之后，都是可以删除的临时分支！

关于hotfix 的命名，大家也可以参考这release分支的命名来！如果我们是修复1.0.0 的线上版本，那么修复之后的版本号应该是是1.0.1，那么我们就可以给这个hotfix 分支取名为hotfix-1.0.1

即：hotfix- + 即将发布的版本号

这个也是仅供参考，如果你有更好的方案，也欢迎在公众号后台留言给我！

在bug 修复分支的生命周期里，我们会用的git操作其实和release分支大致是一样的，不过这里也还是在罗列一下，也是大家可以看着git的变化，把握它们的逻辑！

补充——merge的三种模式

看到这里，关于git 分支的管理模型就已经了解的差不多了额，接下来也该填一下前面挖下的坑了。相信早就有同学疑问，为什么我们的merge 使用的是而不是直接用 。其实除了这两种我们还有一种。这里我们就来区分一下吧！

先看图（改图最左边的图由我本人补充）

1、git merge feature

默认fast-forward 模式，如上图最右边的分支合并，不是没有合并，develop分支的HEAD 直接指给了feature分支的HEAD 然后就呈现了这样的状态，但这种合并是有条件的——当我们从develop分支切出feature分支开始，到feature分支开发完合并到develop分支之前，develop分支都不能有新的提交，才会使用fast-forward模式进行合并。否则即使你用这个命令也会让你以第二种模式合并。

2、git merge --no-ff feature

--no-ff ，看着命令再结合前面提到的默认模式。基本已经猜出其意思了，就是强行关闭fast-forward。如上图中中间的哪一组分支合并图。当我们使用这种模式进行合并的时候，它就会创建出一个新的合并分支节点作为当前分支的HEAD。用这种方式，我们能够更清晰看到分支完成的内容和分支的起止时间。所以更多的时候我们是推荐使用这种合并方式的。

注：当我们在命令行里执行了上面的合并命令后，会弹出上图所示内容。这是通过Vim去修改本次提交的备注。它默认给的是 一般我都用默认，不修改，直接输入然后回车就保存退出了

3、git merge --squash feature

这个模式是将feature分支上的左右的改动提交都合成一个点作为develop的一次commit。通常我们使用的场景是如果我们切出一个分支来修复bug 然后出现了很多的补充提交和小改动的提交，看起来这些都很冗余没有必要，那么我们就可以用这种模式。该模式提交完了的最终形态有点像fast-forward模式。并且它不同于上面两种模式的一点是，你执行了这个命令之后，只是把 feature分支上的所有改动都移植到了develop分支上的相应文件上。接下来我们还需要自己再手动 add . --> commit 一次。可以配合分支合并图的最左边的示意图理解一下！

Git分支管理模型说完了

好了总算把Git分支管理模型这块说完了。在前面两篇分享中，有小伙伴说要跟着这个一起撸。这确实是个不错的主义，只是这次的内容没有太多让大家撸的。但是在这里还是强烈建议大家新建一个GitDemo项目好好理解一下这样的一个git 分支管理模型。虽然在后面的文章中我也会用这套模型来进行git 分支管理，但是毕竟我是一个人在写，所以并不能很好的模拟多人开发的分支管理，所以理解这个模型，大家还是需要亲力亲为的！

这篇文章就到这里吧，另外啰嗦两句，这个系列的文章基本会涉及到我们开发到上线整个流程的内容，所以有的时候像这篇文章一样，写一些需要我们在开发过程中应该有一定认知的东西，而不仅仅停留在一些代码上。

欢迎大家关注我的公众号