Git(三)：分支管理

理解分支

本章介绍Git的杀手级功能之一：分支

分支就 是科幻电影里面的平行宇宙，当你正在电脑前努力学习C++的时候，另⼀个你正在另⼀个平行宇宙里 努力学习JAVA。如果两个平行宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并 了，结果，你既学会了C++又学会了JAVA！

在版本回退里，你已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是一个分支。截止到目前，只有⼀条时间线，在Git里，这个分支叫主分支，即master分支。 再来理解⼀下HEAD，HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支

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

我们可以查看当前master指向的内容：

创建分支

Git支持我们查看或创建其他分支，查看分支的命令为git branch，创建分支dev 的命令为git branch <分支名>

当我们创建新的分支后，Git新建了⼀个指针叫dev， * 表⽰当前 HEAD 指向的分支是 master 分 支。另外，可以通过目录结构发现新的 dev 分支：

此时，master与dev都指向同一个修改：

用图示进行总结：

切换分支

那如何切换到dev分支下进行开发呢？使用git checkout 命令即可完成切换，同时切换后*就在dev分支前面了：

状态图如下：

我们发现HEAD已经指向了dev，就表示我们已经成功的切换到了dev上！ 接下来，在 dev 分支下修改ReadMe⽂件，新增一行内容，并进行一次提交操作：

现在，dev分支的工作完成，我们就可以切换回master分支，发现master分支上的ReadMe没有被修改，并且dev分支和master分支指向的提交是不一样的：

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

合并分支

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

合并后，master就能看到dev分支提交的内容了。此时的状态如图如下所示：

Fast-forward代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。 当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并

删除分支

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

此时的状态如图如下所示：

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

合并冲突

在合并分支时，我们只在dev分支上修改了ReadMe文件，那如果此时也在master分支上修改ReadMe文件呢？这样就会产生冲突，合并分支时就会出错（两个分支上都要add和commit）：

因为Git并不知道如何取舍，此时的状态如图如下所示：

发现ReadMe文件有冲突后，可以直接查看⽂件内容，Git会⽤<<<<<<<，=======， >>>>>>>来标记出不同分支的冲突内容：

此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果

注：git log --graph --pretty=oneline --abbrev-commit命令可以以图示的方法查看分支的合并状态，对应的图示如下：

分支管理策略

通常合并分⽀时，如果可能，Git会采用Fast forward 模式。还记得如果我们采用Fast forward 模式之后，形成的合并结果是什么呢？回顾⼀下

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

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

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

Git支持我们强制禁用Fast forward 模式，那么就会在merge时生成⼀个新的commit ，这样，从分支历史上就可以看出分支信息。 下面我们实战⼀下 --no-ff方式的git merge

首先，创建新的分支 dev2 ，并切换至新的分支:

切回 master 分支，开始合并:

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

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

分支策略

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

• 首先，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来删除

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

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

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

我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有⼀定风险的。 是因为在合并分支时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。我们无法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项目中，代码冲突不只⼀两行那么简单， 有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。 此时的状态为：

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

删除临时分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。 添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分支搞乱了，所以，每添加⼀个新功能，最好新建⼀个分支，我们可以将其称之为feature 分支，在上面开发，完成后，合并，最 后，删除该feature 分支

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

此时就可以使用git branch -D命令！