首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

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

其实阮一峰老师写了关于git的一个系列文章。如果对git还不太熟悉的,非常推荐阅读,图文并茂,浅显易懂!

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

小声声明:这部分几乎所有的图片都引用自《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 分支管理,但是毕竟我是一个人在写,所以并不能很好的模拟多人开发的分支管理,所以理解这个模型,大家还是需要亲力亲为的!

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

好了,下一篇应该会写一些开发过程中能够提高我们工作效率的一些插件。你可以在我的公众号下面回复「Settings」,提前拿到我的Android Studio的配置导入到自己的Android Studio里了解一下!

欢迎大家关注我的公众号

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180729A1HBYX00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券