「Do.008」Android 实战项目（3）——Git 分支管理模型

首发公众号： Android程序员日记
做者： 贤榆的榆
若是你以为有帮助欢迎 关注、赞扬、转发
阅读时间：5622字 15分钟

一般当咱们在进行一个正式项目的时候，必定的分支管理是必要，这里推荐你们阅读两篇文章，我本身也是从这两篇文章中受益不浅。

第一篇是国外行家Vincent Driessen 的《A successful Git branching model》
地址：https://nvie.com/posts/a-succ...

第二篇阮一峰老师的《Git分支管理策略》
地址：http://www.ruanyifeng.com/blo...

其实阮一峰老师写了关于git的一个系列文章。若是对git还不太熟悉的，很是推荐阅读，图文并茂，浅显易懂！

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

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

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

• 一种是主要分支
• 一种是临时分支

主要分支

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

一、master分支

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

二、devleop分支

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

又一个git 命令能够学一下

//在develop分支下运行下面命令
git push origin develop

将本地develop分支推送至远端仓库，若是远端没有develop会自动建立！

临时分支

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

• feature（功能分支）
• hotfix（bug修复分支）
• release-（发布版分支）

一、feature（功能分支）

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

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

在开发过程当中会用到的：

//从devleop切出一个新的分支命名为
//feature_name(这个名字你能够自定义)
git checkout -b feature_name develop

//检查项目中是否有未进行版本控制和已修改的文件
git status 

//将项目当前目录下全部文件到暂存区
git add .

//提交暂存取里的代码到本地库
git commit -m"提交log"

//固然你也可能会用到上面讲到过的一个命令
//这个只取决于你是否想将这个临时分支，推送到远程服务器进行管理
git push origin feature_name

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

//切换回develop分支
git checkout develop

//将feature_name分支合并到develop
git merge --no-ff feature_name
    
// 删除本地的feature_name 分支
git branch -d feature_name
    
//将develop分支推送到远端服务器,必定要先pull再push
git pull origin develop 
git push origin develop

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

二、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指令流程。

//首先从develop分支牵出release-1.0.0分支
git checkout -b release-1.0.0


//接着咱们会检查、添加到缓存区、提交到本地
git status
git add .
git commit -m"修复bug2018"

//确认release-1.0.0的分支没有问题了，咱们就将分支合并到master分支
git checkout  master
git merge --no-ff release-1.0.0

//在master分支上打上tag
git tag -a v1.0.0 -m"release v1.0.0"
# -a:后面跟的是标签名；
# -m:后面跟的是改标签的说明(通常能够不用加-m)

//推送master分支和tag到远程
git pull origin master
git push origin master
git push --tags

//合并分支到develop
git checkout develop
git merge --no-ff release-1.0.0

//最后能够删除分支而后推送develop到远程了。
git branch -d release-1.0.0
git pull origin develop 
git push origin develop

三、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的变化，把握它们的逻辑！

//首先从develop分支牵出release-1.0.0分支
git checkout -b hotfix-1.0.1

//修复完成后去检查、添加到缓存区、提交到本地
git status
git add .
git commit -m"修复线上bug"

//确认hotfix-1.0.1的分支测试经过，咱们就将分支合并到master分支
git checkout  master
git merge --no-ff hotfix-1.0.1

//在master分支上打上tag
git tag -a v1.0.1 -m"hotfix-v1.0.1"  
# -a:后面跟的是标签名；
# -m:后面跟的是改标签的说明(通常能够不用加-m）

//推送master分支和tag到远程
git pull origin master
git push origin master
git push --tags

//合并分支到develop
git checkout develop
git merge --no-ff hotfix-1.0.1

//最后能够删除hotfix-1.0.1分支而后推送develop到远程了。
git branch -d hotfix-1.0.1
git pull origin develop 
git push origin develop

补充——merge的三种模式

看到这里，关于git 分支的管理模型就已经了解的差很少了额，接下来也该填一下前面挖下的坑了。相信早就有同窗疑问，为何咱们的merge 使用的是git merge --no-ff 而不是直接用git merge 。其实除了这两种咱们还有一种git merge —squash。这里咱们就来区分一下吧！
先看图（改图最左边的图由我本人补充）

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

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

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

三、git merge --squash feature
这个模式是将feature分支上的左右的改动提交都合成一个点做为develop的一次commit。一般咱们使用的场景是若是咱们切出一个分支来修复bug 而后出现了不少的补充提交和小改动的提交，看起来这些都很冗余没有必要，那么咱们就能够用这种模式。该模式提交完了的最终形态有点像fast-forward模式。而且它不一样于上面两种模式的一点是，你执行了这个命令以后，只是把 feature分支上的全部改动都移植到了develop分支上的相应文件上。接下来咱们还须要本身再手动 add . --> commit 一次。能够配合分支合并图的最左边的示意图理解一下！

Git分支管理模型说完了

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

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

好了，下一篇应该会写一些开发过程当中可以提升咱们工做效率的一些插件。你能够在个人公众号下面回复「Settings」，提早拿到个人Android Studio的配置导入到本身的Android Studio里了解一下！