---

前言

本篇博客开始介绍Git的杀手级功能之一 : 分支.分支就是科幻电影里面的平行宇宙,当你正在电脑前努力学习C++的时候,另一个你正在另一个平行宇宙里努力学习Java.

---

正文开始!

一、理解分支

接着上面的阐述 : 如果两个平行宇宙互不干扰,那对现在的你也没有什么影响.不过,在某个时间点,两个平行宇宙合并了.结果,你既学会了C++,又学会了Java.

在版本回退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就可以理解为时一个分支.截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支.

再来理解一下HEAD,HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支.

每次提交,master分支都会向前移动一步.再这样,随着你不断提交,master分支的线也越来越长,而HEAD只要一直指向master分支即可指向当前分支.

通过查看当前的版本库,我们也能清晰的理出思路:

二、创建分支

Git支持我们查看或者创建其他分支,在这里我们来创建第一个自己的分支dev,对应的命令为 :

当我们创建新的分支后,Git新建了一个指针叫dev,*代表当前HEAD指向的分支是master分支.另外,可以通过目录结构发现新的dev分支 :

发现目前dev和master指向同一个修改.并且也可以验证下HEAD目前是指向master的.

一张图总结 :

三、切换分支

那如何切换到dev分支下进行开发呢?使用git checkout命令即可完成切换,示例如下 :

现在,dev分支的工作完成,我们就可以切换回master分支 :

切换回master分支后,发现ReadMe文件中新增的内容不见了!!!赶快切回dev看看 :

在dev分支上,内容还在.为什么会出现这个现象呢?我们来看看dev分支和master分支指向,发现两者指向的提交是不一致的 :

看到这里就能明白了,因为我们是在dev分支上提交的,而master分支此刻的提交点并没有变,此时的状态如下图所示 :

当切换到master分支以后,HEAD指针就指向了master.

四、合并分支

为了在master主分支上能看到新的提交,就需要将dev分支合并到master分支,示例如下 :

git merge命令用于合并指定分支到当前分支.合并后,master就能看到dev分支提交的内容了,此时的状态如下图所示 :

Fast-forward代表"快进模式",也就是直接把master指向dev的当前提交,所以合并速度非常快.当然,也不是每次合并都能Fast-forward,后续再带大家了解其他方式的合并.

五、删除分支

合并完成后,dev分支对于我们来说就没用了,那么dev分支就可以被删除掉,注意如果当前正处于某个分支下,就不能删除当前分支,如 :

而可以在其他分支下删除当前分支, 如 :

此时的状态如下图所示 :

因为创建、合并和删除分支非常快,所以Git鼓励你使用分支完成某个任务,合并后再删掉分支,这和直接在master分支上工作效果是一样的,但过程更安全.

六、合并冲突

可是,在实际分支合并的时候,并不是想合并就能合并成功的,有时候可能会遇到代码冲突的问题.为了演示这个问题,创建一个新的分支dev1,并切换至目标分支,我们可以使用git checkout -b dev1一步完成创建并切换的动作,示例如下 :

在dev1分支下修改ReadMe文件,更改文件内容如下,并进行一次提交,如 :

切换至master分支,观察ReadMe文件的内容 :

我们发现,切回来以后,文件内容又变成了老的版本,这种现象很正常,我们现在也完全能理解.此时在master分支上,我们对ReadMe文件再进行一次修改,并进行提交,如下 :

现在,master分支和dev1分支各自都分别有新的提交,变成了下图 :

这种情况下,Git只能试图把自己的修改合并起来,但这种合并就可能会有冲突,如下所示 :

发现ReadMe文件有冲突后,可以直接查看文件内容,要说的是Git会用<<<<<<<,=======,>>>>>>>来标记出不同分支的冲突内容,如下所示 :

到这里冲突就解决完成,此时的状态变成了

用带参数的git log也可以看到分支的合并情况,具体大家可以自行搜索git log的用法 :

最后不要忘记删除dev1分支!!!

七、分支管理策略

通常合并分支时,如果可能,Git会采用Fast forward模式.还记得如果我们采用Fast forward模式之后,形成的合并结果是什么呢?回顾一下

在这种Fast-forward模式下,删除分支后,查看分支历史时,会丢掉分支信息,看不出来最新提交到底是merge进来的还是正常提交的.

但在合并冲突部分,我们也看到通过解决冲突问题,会再进行一次新的提交,得到的最终状态为 :

那么这就不是Fast forward模式了,这样的好处是从分支历史上就可以看出分支信息.例如我们现在已经删除了在合并冲突部分创建的dev1分支,但依旧能看master其实是由其他分支合并得到 :

Git支持我们强制禁用Fast forward模式,那么就会在merge时生成一个新的commit,从分支历史上就可以看出分支信息.

下面我们实操一下--no-ff方式的git merge.首先,常见新的分支dev2,并切换至新的分支:

修改ReadMe文件,并提交一个新的commit :

切回master分支,开始合并 :

请注意--no-ff参数,表示禁用Fast forward模式.禁用Fast forward模式后合并会创建一个新的commit,所以加上-m选项,把描述写进去.

合并后,查看历史分支 :

可以看到,不使用Fast forward模式,merge后就像这样 :

所以在合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而Fast forward合并就看不出来曾经做过合并.

八、分支策略

在实际开发中,我们应该按照几个基本原则进行分支管理 :

首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活.

那在哪里干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;

你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了.

所以,团队合作的分支看起来就像这样 :

九、bug分支

假设我们现在正在dev2分支上进行开发,开发到一半,突然发现master分支上面有bug,需要解决.在Git中,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除.

可现在dev2的代码在工作区开发了一半,还无法提交,怎么办?例如 :

Git提供了git stash命令可以将当前的工作区信息进行存储,被存储的内容可以在将来某个时间恢复出来.

用git status查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复bug.

储藏dev2工作区之后,由于我们要基于master分支修复bug,所以需要切回master分支,再新建临时分支来修复bug,示例如下 :

修复完成后,切换到master分支,并完成合并,最后删除fix_bug分支 :

至此,bug的修复工作已经做完了,我们还要继续回到dev2分支进行开发.切换到dev2分支 :

工作区是干净的,刚才的工作现场存到哪去了?用git stash list命令查看 :

工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,如何恢复现场呢?我们可以使用git stash pop命令,恢复的同时会把stash也删了,示例如下 :

再次查看的时候,我们发现已经没有现场可以恢复了.

另外,恢复现场也可以采用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;

你可以多次stash,恢复的时候,先用git stash list查看,然后恢复指定的stash,用命令git stash apply stash@{0}即可.

恢复完代码之后我们便可以继续完成开发,开发完成后便可以进行提交,例如 :

但我们注意到了,修复bug的内容,并没有在dev2上显示.此时的状态图为 :

master分支目前最新的提交,是要领先于新建dev2时基于master分支的提交的,所以我们在dev2中当然看不见修复bug的相关代码.

我们最终目的是要让master合并dev2分支的,那么正常情况下我们切回master分支直接合并即可,但这样其实是有一定风险的.

是因为在合并分支时可能会有冲突,而代码冲突需要我们手动解决(在master上解决).我们无法保证对于冲突问题可以正确地一次性解决掉,因为在实际的项目中,代码冲突不只一两行那么简单,有可能几十上百行,甚至更多,解决的过程难免手误出错,导致错误的代码被合并到master上.此时的状态为 :

解决这个问题的一个好的建议就是 : 最好在自己的分支上合并master,再让master去合并dev,这样做的目的是有冲突可以在本地分支解决并进行测试,而不影响master.此时状态为 :

对应的实操演示如下,要说明的是,以下演示merge操作

十、删除临时分支

软件开发中,总有无穷无尽的新功能要不断添加进来.

添加一个新功能时,你肯不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个分支,我们可以将其称之为feature分支,在上面开发,完成后,合并,最后删除该feature分支.

可是,如果我们今天正在某个feature分支上开发了一半,被产品经理突然叫停,说是要停止新功能的开发.虽然白干了,但是这个feature分支还是必须就地销毁,留着已经无用了.这时使用传统的git branch -d命令删除分支的方法是不行的.演示如下 :

直接使⽤传统的删除分⽀的⽅法不⾏，按照提⽰，有了如上⽅式git branch -D [分支名].

---

总结

(本章完!)