第二个月你在山上偶然帮助了一个老头，却没想到该老头是个武林大师，听闻了你的经过后，点化了你。于是你学会了一门新技能：分身术。这个分身术不是普通的分身，在分身期间该分身所学习的技能，在与你重新合并的时候，都会转化为你所有。于是你在第二个月，你本体学习降龙十八掌，分身学习辟邪剑法，等第二个月结束后，分身合体，你同时掌握了这两种技能。而你的对手却只会了降龙十八掌.

第三个月你们参见比赛，不出意外，你凭借多学的一门技术轻松战胜了对手。

如下：

以上你本体学习的所有内容称之为主线(master主分支)，你的分身学习的称之为支线.

这是上一章那个图片：

上一章我们也说了，这里不做过多赘述，就是HEAD指针指向了master，而master指向了master主分支上最新一次的提交，如下：

而有分支的提交如下：

具体是如何做的，以及会有一些什么问题，请继续向下看.

创建分支

刚才一直在说HEAD指针，它指向了master，而master又指向了master主分支上最新一次的提交.

同时也说明1.HEAD指针指向的分支就是我们正在工作的分支。

2.而且HEAD可以指向其他分支，代表此时在该分支上工作。

如当我们创建一个分支时，假设分支名为dev-1，当我们切到该分支上时，HEAD指针便不再指向master，而是指向dev-1，而dev-1指向了dev-1分支上的最新一次提交。

那如何创建一个分支呢？

命令如下：

git branch [分支名]

该命令可以创建一个分支。

同时，我们可以使用下面的命令查看当前所有的分支。

git branch

如下：

其中 * 代表当前所处的分支。可以看到我已经创建了一个名为dev-1的分支。

注意：dev分支是基于当前分支最新一次提交的版本上创建的。

此时我们再查看一下.git中refs/heads下两个分支的内容：

可以发现两者的commit id是完全相同的，即我创建的dev-1分支是在当前master主分支上最新一次提交的基础上创建的.

如下：(图中的分支名是dev，我写的是dev-1，不一样，但不影响，只是名字不同)

切换分支

我们虽然刚才创建了dev-1分支，但是我们通过git branch发现，我们当前所处的分支还是在master分支上：

我们该如何切换到dev-1分支呢？

使用命令：

git checkout [分支名]

即可切换到制定分支。

此时我们发现已经切换到dev-1分支上，并且HEAD指针已经指向了dev-1，说明我此时已经在dev-1上开始工作了，所以此时的分支关系如下：

合并分支

当我们切换到dev-1分支上后，我们先对ReadMe文件进行修改：添加一行"test on dev-1"

然后我们退出保存，然后add 到暂存区，并且commit提交：

此时我们再切换回到master主分支上，再次查看ReadMe内容：

我们发现，我们在dev-1分支上添加的那一行不存在，这是什么原因呢？

我们再来看一下刚创建dev-1分支完成时的状态：

此时master和dev-1重合，因为是刚创建，dev-1指向master最新一次提交。

当在dev-1分支上添加一行内容，并且add 和commit后，此时状态成为了这样：

此时master主分支已经落后于dev-1分支的一个提交了，所以master之所以看不到新添加的一行，是因为master分支还没有更新，即还没有与dev-1分支进行合并。

所以此时我们需要切换到主分支上，然后合并dev-1分支，分支合并命令如下：

git merge [分支名]

该命令会使指定分支合并到当前分支。

合并完成后，新增加的一行我们也就能看到了：

Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。
当然，也不是每次合并都能 Fast-forward，也会其他⽅式的合并，这里不再多说。

此时的状态如下：

删除分支

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

使用如下命令删除分支：

git branch -d [分支名]

可以发现dev-1分支已经被删除掉了。

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

合并冲突

可是，在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。

冲突主要是发生在这样的场景:在当前master主分支上新建了一个dev分支，然后dev分支commit提交后，master主分支此时并没有直接合并，而是也对dev分支上修改的文件也做了修改，此时master主分支再合并，就会出现问题，因为git也不知道是保留dev分支上的修改还是master主分支上的修改。所以需要我们手动解决冲突。

下面做一个演示：

教大家一个命令，可以直接创建并且切换到该新建的分支：

git checkout -b [分支名]

切换到新分支dev1上上之后，我添加了如下一行：

在commit提交后，我切回到master主分支上，此时由于我还没有合并，所以刚才添加的那一行并没有显示，我也在相同的位置添加上如下一行：

此时我commit后，再在master分支上，再进行合并，便会出现下面的合并冲突问题：

此时我们打开冲突的文件：

蓝色框，即HEAD指针指向的分支上(当前分支)的修改是modify on master

粉色框，即dev分支上的修改是 modify on dev1

我们此时有三种选择：

1.保留HEAD的更改

2.保留dev1的更改

3.保留HEAD和dev1的更改.

此时我决定只保留HEAD的更改，于是我把出HEAD指向的那一行以外的内容全部删除，如下：

退出保存后，我们再次add和commit提交，（再次提交很重要，切勿忘记）冲突便成功解决了：

此时我们分支的状态如下：

bug分支

假设我们现在正在dev2分支上进行开发，还没有开发完成，突然发现master主分支上有bug需要解决。在Git中，每个bug都可以通过在master分支上开一个临时分支进行解决，修复后，合并分支，再将临时分支删除。

因此我们需要先回到master分支上，开一个bug分支然后解决完后，再回到dev2分支进行工作，但问题是我现在dev2还没有开发完，如果直接切回master，那内容就会丢失，所以我们需要现将dev2工作区中的内容保存起来。

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

同样拿一个示例演示：

在dev2分支下，我在ReadMe文件中，加入以下一行代码：

此时由于master分支上出现了bug，我需要将当前dev2分支上的内容保存起来，然后切回到master分支：

然后我在开一个分支用来修复bug，假设在ReadMe文件中该行少了三个叹号：

然后修复完成后，我们add并commit提交，切换到master分支，与该分支进行合并：

此时master分支上的bug修复完毕了，我们需要继续回到dev2分支上工作。

切换到dev2分支上后，首先需要恢复我们上次工作区的修改变动，

使用

git stash pop

恢复的同时会把 stash 也删了.

可以发现ReadMe内容恢复了，但是修复bug后的内容，并没有在dev2中显示，此时的状态图为：

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

当我们完成dev2的开发工作时，我们add并commit提交后，

我们此时能切回到master分支然后直接合并吗？

答案是可以，但是是有风险的，这是因为dev2和master在合并分⽀时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。我们无法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单，有可能几十上百行，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。得不偿失，如果这么做，此时的状态图如下：