git第六讲_git的分支命令详解

经过上一讲，我们已经了解了git非常重要的三个组件:blob、commit、tree，这三个组件都是以二进制的方式存储的，而且都是用hash码作为主键的唯一名称。这一讲我们将详细的介绍git的分支。

分支在项目的开发过程中是非常重要的，分支旨在解决版本管理之中的冲突问题。分支的使用一定要在整个项目团队中达成一致，否则分支太多，最后合并的时候会存在一大堆的问题，目前已经有了一套成熟的分支管理体系git-flow，这套体系我们会在下一讲中详细介绍，这一讲我们主要介绍git和分支相关的各种命令。

首先建立自己的git目录。进行如下操作

E:\teacher\git_teacher\06>git initInitialized empty Git repository in E:/teacher/git_teacher/06/.git/***完成工厂的创建E:\teacher\git_teacher\06>echo a > a.txtE:\teacher\git_teacher\06>git add .E:\teacher\git_teacher\06>git commit -m "init"[master (root-commit) 910f9dc] init 1 file changed, 1 insertion(+) create mode 100644 a.txt ***完成第一个版本的提交E:\teacher\git_teacher\06>echo a1 > a1.txtE:\teacher\git_teacher\06>git add .E:\teacher\git_teacher\06>git commit -m "add a1.txt"[master 837caf4] add a1.txt 1 file changed, 1 insertion(+) create mode 100644 a1.txt***完成第二个版本的提交E:\teacher\git_teacher\06>git logcommit 837caf47b871acf0ef78c69617ea9ee76377bfa7Author: ynkonghao <[e-mail]>Date:   Thu Dec 8 23:14:14 2016 +0800    add a1.txtcommit 910f9dcb8437f63cbde73795408e1881854e2ea9Author: ynkonghao <[e-mail]>Date:   Thu Dec 8 23:13:47 2016 +0800    init**通过git log发现已经存在两个版本了。

通过以上操作基本完成了项目的初始化操作，这里我们建立了两个版本。接下来我们使用下一个命令来创建一个分支。

git branch b1

这样就创建好了一个分支b1,可以通过

git branch

查询所有的分支

我们发现有两个分支，一个是master，另外一个是刚才创建的b1，master是绿色的并且前面有个*，表示我们目前处于master分支。

现在的状态：有两个分支，有两个文件a.txt和a1.txt。下一步我们需要转换到b1这个分支中，使用下面的命令

git checkout b1

此时就可以转换到b1的分支中，同样我们也可以通过如下命令完成分支的创建和转换

git checkout -b b2

这将会创建一个分支b2，并且切换到分支b2中

我们就在b2分支中进行一些修改，并且完成一次版本的提交。

此时在b2分支中就有了三次提交，而且有了三个文件，我们再切换回分支master看看情况。

我们发现master分支看不到b2分支的任何信息，而且文件也没有在b2分支中添加的b2.txt。我们继续在master分支中添加一个文件m.txt。然后完成版本的提交

此时在master中有3个文件:a.txt,a1.txt,m.txt,其中m.txt是在分支创建之后才创建，而且目前master分支也有三个commit，切换回b2分支，查询文件

我们发现在b2上并不存在master在创建分支之后的信息，现在我们分支的情况如下图所示

此时master分支的修改不会在b1或者b2中有所呈现。我们继续如下操作，选择b2分支，然后再次创建一个分支b2_1

此时需要注意的是我们是在b2分支上创建的分支b2_1，所以b2_1分支仅仅只能看到b2分支上的东西，这里就得出了一个结论，在某个分支上创建的分支是以该分支为基础的。此时在b2_1中添加文件并且完成提交。并且切换到b1中进行一次版本的提交,再在b2中进行一次版本提交，执行的命令如下

git checkout b2_1echo b2 > b2_1.txtgit add .git commit -m "b2_1 add file"git checkout b1echo b1 > b1.txtgit add .git commit -m "b1 add file"git checkout b2echo b2 >> b2.txtgit add .git commit -m "b2 update b2.txt"

下图是当前每个分支的情况

有没有发现，现在分支已经开始混乱了，我们通过下图来理解分支目前的状态

我们最早的master分支有两次提交，之后创建了b1和b2分支，并且分别完成了一次提交，然后在master上也完成了一次提交，在b2分支上又创建了新的分支b2_1，然后完成了一次提交。大家有没有发现不管怎么画图，当分支变多之后也很难进行管理，这也就是为什么我们要确定分支管理思路的原因，很幸运，git-flow为我们定义了一套合理的分支管理流程，我们将会在下一讲来进行介绍。

现在我们已经了解了分支的创建操作，之后我们需要对分支进行合并，刚才我们的联系是人为避开了冲突，我们先了解分支合并步骤，之后再来看产生冲突之后的情况。分支的合并非常的简单，只要在需要合并的分支上使用git merge 要合并的分支就完成了，下面的操作完成了在master分支上合并b1

git checkout mastergit merge b1

合并非常的顺利，但是注意，合并完成之后，会产生一个新的commit组件，通过cat-file查询这个组件，我们会发现该组件有两个parent，看看这两parent的id，就是原来的master的最新版本id和b1的最新版本的id。我们发现一个版本是可能存在多个parent的，只要分支进行合并之后，parent指向了它的上一个版本。

接着我们来合并b2分支，b2分支有些特殊，因为b2分支上还存在b2_1分支。

git merge b2

我们发现合并非常的顺利，git并不会将b2_1的内容合并进来，我们可以继续执行git merge b2_1完成合并，也同样顺利完成，git log --pretty=oneline查询，我们发现每次合并都产生了新的commit组件

我们发现git的分支合并非常的灵活高效，在合并完分支之后我们就需要删除多余的分支，使用-d参数完成删除

git branch -d b1

使用以上命令就完成了对b1分支的删除，之后我们来删除b2分支，我们发现b2分支的删除也非常的顺利，而且删除完成之后b2_1分支依然存在。我们发现虽然b2_1是在b2的基础上创建的，但两者之间的关联其实并不密切（后面我们会了解到分支的名称仅仅只是那个hashid的标示，删除了分支，其实版本依然是存在的）。而且，我们发现b2_1上的parent依然是我们删除了b2分支的版本。

但是此时执行git branch -d b2_1，我们发现报了一个错误。他告诉我们b2_1并没有被完全合并，由于它是在b2上衍生出来的分支，应该要先合并到b2中，但是此时b2已经被删除了，我们可以使用git branch -D b2_1强行删除分支。所以虽然git对分支的合并的管理非常灵活，但是在实际使用中，如果在某个分支上创建了子分支，依然应该先完成子分支的合并再将其合并到master中。

下面我们演示一个带冲突的分支合并，当两个分支同时修改某个文件的相同行时就会发生这个冲突。我们会执行如下一组命令

echo co > co.txtgit add .git commit -m "master add co.txt"git checkout -b bcecho changeByBc > co.txtgit add .git commit -m "bc update co.txt in first line"git checkout masterecho changeByMaster > co.txtgit add .git commit -m "master update co.txt in first line"

此时两个版本中co.txt的内容不一样，而且是在同一行，我们进行一下合并

git checkout mastergit merge bc

我们发现产生冲突了，在co.txt中显示了冲突的位置，当发生这个冲突，我们只能在团队的内部进行协调解决这个冲突，这是分支合并是修改了相同文件，带来的必然结果，只能人工解决或者通过SourceTree之类的工具选择使用那个版本。所以分支虽然给我们带来了很多便利，但是一定要合理的规划好分支的使用策略才能让分支发挥出最大的功效，下一讲我们将介绍基于git-flow的分支管理策略。