Git分支管理

目录

1.分支管理

1.1理解分支

1.2创建分支

1.3切换分支

1.4合并分支

1.5删除分支

1.6合并冲突

2.分支管理策略

2.1分支策略

3.BUG分支

4.删除临时分支

5.小结

---

1.分支管理

1.1理解分支

本章开始介绍Git的杀手级功能之一(注意是之一， 也就是后面还有之二，之..... :分支。分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习C++的时候，另一个你正在另一个平行宇宙里努力学习JAVA。

如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并
了，结果，你既学会了C++又学会了JAVA!

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

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分 支的线也越来越长，而HEAD只要一直指向master分支即可指向当前分支。
通过查看当前的版本库，我们也能清晰的理出思路:

1.2创建分支

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

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

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

如图所示：

1.3切换分支

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

如图所示：

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

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

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

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

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

当切换到master分支之时，HEAD 就指向了master,当然看不到提交了!

1.4合并分支

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

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

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

1.5删除分支

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

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

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

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

1.6合并冲突

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

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

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

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

现在，master分支和dev1分支各自都分别有新的提交，变成了这样:?

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

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

此时我们必须要手动调整冲突代码，并需要再次提交修正后的结果! ! (再次提交很重要,切勿忘记)

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

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

最后，不要忘记dev1分支使用完毕后就可以删除了:

2.分支管理策略

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

在这种Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提
交到底是merge进来的还是正常提交的。
但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交， 得到的最终状态为:

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

Git支持我们强制禁用Fast forward 模式，那么就会在merge时生成一个新的commit，这样，
从分支历史.上就可以看出分支信息。
下面我们实战一下--no-ff方式的git merge。首先，创建新的分支dev2，并切换至新的分支:

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

切回masterl分支，开始合并:?

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

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

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

2.1分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理:
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在.上面干活;
那在哪干活呢?干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样:

3.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操作，没有使用--no-ff,但上述的图示是
禁用Fast forward 了模式后得出的，主要是为了方便解释问题。

4.删除临时分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时，你肯定不希望因为一些实验性质的代码,把主分支搞乱了，所以，每添加一个新功能，最好新建一个分支，我们可以将其称之为feature 分支，在上面开发，完成后，合并，最
后，删除该feature分支。
可是，如果我们今天正在某个feature分支.上开发了一半，被产品经理突然叫停，说是要停止新功
能的开发。虽然白干了，但是这个feature分支还是必须就地销毁，留着无用了。这时使用传统
的git branch -d 命令删除分支的方法是不行的。演示如下:

直接使用传统的删除分支的方法不行，按照提示，有了如下方式:

5.小结

分支在实际中有什么用呢?假设你准备开发一-个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支.上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
并且Git无论创建、切换和删除分支，Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。