今天我们要学习的是Git一个非常重要的功能——分支操作，如果还没有看过前两次Git操作的小伙伴可以点击这里：

https://blog.csdn.net/qq_67693066/article/details/136161046

https://blog.csdn.net/qq_67693066/article/details/136186578

理解分支

在学习分支操作之前，我们要理解一下分支，分支简单一点来说就是平行宇宙：
大家看过蜘蛛侠的《平行宇宙》吗，假设这是现在我身处的时空：

但是可能还有另一个时空的我正在干其他的事：

这个时候时空混乱，第一平行宇宙和第七平行宇宙竟然重合了！

这个时候造成了时空大混乱，地球危在旦夕，叭叭叭…。总之Git的分支和这个平行宇宙的概念差不多。

查看当前分支

git branch 查看有几个分支

git branch可以查看当前所处的分支：

星号在哪个分支前，就代表我们在哪个分支。我们可以看到我们现在在master这个分支下：
我们也可以查看.git/refs/heads来查看我们到底有几个分支：

不知道大家还记不记得我们之前版本库中的HEAD指针，现在我们处在master分支下，我们的HEAD指针就会指向master，master会指向我们最新一次的提交：

我们可以打印一下master里面的内容：

git branch + 新分支的名字 创建新分支

我们可以git branch + 新分支的名字用来创建新分支：
比如我们创建一个dev的新分支：

我们看到了我们的新分支，我们也可看看heads文件下有没有多什么东西：

发现多了一个dev，我们可以把它打印出来看看：

发现有点眼熟，我们再打印更清楚一点：

发现这是master上最新一次的提交，dev也指向他了：

git checkout -b 分支名 直接创建并切换到该分支下

git checkout -b 分支名 直接创建并切换到该分支下

切换分支

git checkout 分支名 切换到指定分支

我们可以用 git checkout 分支名，切换到指定分支：

这个时候我们再来git branch：

星号在dev前，说明当前在dev分支下

我们尝试在dev分支下做一些改动：
我在dev分支下创建一个新文件：

我把这个新的文件提交到版本库中：

这个时候我们的时间线上多了一条dev上的事件：
这个时候，如果我们再切换到master分支下：
会发现，我们刚才建的文件不见了，这其实也很好理解，你在dev分支下的操作，关你master分支什么事？我们切回来了master，自然看不到dev下的文件了。

合并分支

要想master看见dev下的操作，我们就要合并dev到master，要合并dev首先我们要回到master分支上。

git merge 分支名 合并指定名字的分支

git merge 分支名，合并指定名字的分支：

这个时候，我们再来看看我们的文件：
发现有我们新建的文件了，这个时候master指向了dev事件的节点：

我们打印一下master里面的内容看看：

并且仓库是干净的状态：

删除分支

git branch -d 分支 删除指定分支

我们可以用git branch -d 分支 删除指定分支（首先要切到在非删除的分支上）：
比如我想在master分支上删除dev分支（删除dev这个分支的操作不能在dev上，不能自己删除自己）：
这个时候dev就被删除了：

合并冲突

我们现在有这么一个情况，我们现在有dev，和master两个分支，且两个分支上都有new_file的文件（文件内容都是相同的，都是aaa）：

我们在master下看一下这个New_file：
我们切换到dev下，查看New_file：

我们现在对dev下的New_file中内容改为bbb：
然后提交：

这个时候dev分支有变化：
我们切换到master分支下，修改master下的New_file文件改为ccc：
然后提交：

这个时候我们如果合并，就会出现问题：

因为两个分支上都修改了New_file，git并不知道你要保留哪一行，所以，这个时候我们进入New_file：
从中间的等号线划开，上面是我们master（HEAD指向的的分支）的修改，下面是dev分支的修改，我们要哪个就保留哪个：
我们保留dev的：

完成之后，我们要重新add，commit一次，这个非常重要：

这个时候，我们就合并了dev：

git log --graph --pretty=oneline --abbrev-commit 通过日志查看合并情况

合并模式

Fast——forward模式

如果我们合并分支之后，可以看看有没有这一行：
有这一行，就说明是Fast——forward模式，在这个模式下我们通过日志查看合并情况是不能看到新的修改是合并的还是自己提交的。（就像这张图）：

但是，在合并冲突部分，我们也看到通过解决冲突问题，会再进行⼀次新的提交，那么这就不是 Fast ——forward 模式了，这样的好处是，从分支历史上就可以看出分支信息。就像我们上图那样：

no-ff模式

git支持我们禁用Fast——forward模式，我们只需要在合并的时候带上–no-ff：

git merge --no-ff -m "XXXXXXXXX" 你要合并的分支

这个时候的状态为：

分支策略

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

首先，master分支应该是非常稳定的，也就是仅⽤来发布新版本，平时不能在上面干活；
一般都在dev的分支上工作，等到开发完成，才往master合并

多人协作开发一般都像这样：

bug分支

有时候，master上有bug，导致程序有问题，这个时候我们不能直接在master上直接修，我们要在其他分支修好，然后才往master上并：

假设现在有这么一个场景：

假设，我的的dev2下的My_file正在进行开发：

首先我们要做的，我们的My_file文件在开发，我们的把它先储存起来：

git stash 储存改动

我们可以用git stash 储存改动：

我们可以看看：

git stash list

这里提一下，我们可以用git stash list来查看我们的改动：

这个stash文件里储存有我们的改动。这个时候我们再看My_file：
发现改动已经没有了，因为我们的改动已经储存起来了。

新建分支来解决bug

这个时候我们创建一个新的分支，来解决我们的问题，首先我们先切到master上：
切到fix_bug上，然后我们进行修复：
记得add，commit：

我们情况是这样的：

这个时候，我们往master上合并就可以了：

换到master上，我们看一下：
这个时候，我们修好了bug。

git stash pop 恢复修改

这个时候我们完成了bug的修复，这个时候我们dev2操作上修改我们要恢复过来，我们切到dev2上：
执行git stash pop


这个时候我们得进度又回来了，我们继续开发：
这个时候注意，我们dev2上并没有合并fix_bug，如果此时直接合并到master上，肯能会有更大的bug，所以在这里我们dev2合并master：

强制删除分支git branch -D 分支名

这里说一下，如果我们有分支，进行了一些工作，但是还没有合并到master上，这个时候git会保护这个分支不让我们删：

这个时候把d换为D即可：