带你解析git的基础功能(二)

一.前言

掌握 Git 分⽀管理，从分⽀创建，切换，合并，删除的整个⽣命周期，灵活进⾏各种场景下的分⽀管理，学习常⻅分⽀管理策略。

二.什么是git的分支管理

Git 的分支管理是 Git 的核心功能之一。它允许您在同一 Git 仓库中跟踪多个工作流程。
为什么需要分支管理，假设这个宇宙的你，正在看动漫，另一个宇宙的你正在拯救全人类。如果两个宇宙互不干扰，你既拯救了世界，也看了动漫。岂不两全其美。我们在不同的时间线做了不同的事情，然后我们再把相同的时间线合并以后，就能完成两件事情。
拿到git里面来说，我们在不同的分支不断开发不同的版本，时间线不断的往前推进。master的分支越来越多，我们就需要对分值进行管理，也就是合并和删除操作。

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

三.git的分支管理的相关操作

3.1 创建分支

例如要创建分支，您可以使用 git branch 命令。

git branch <branch_name>

例如，要创建一个名为 feature 的分支，您可以使用以下命令：

git branch feature

这将创建一个新的分支，并将其指向当前分支的最新提交。
下面就是新建dev分支的图示：

3.2 切换分支

那如何切换到 dev 分⽀下进⾏开发呢？
要切换分支，您可以使用 git checkout 命令。

git checkout <branch_name>

例如，要切换到 feature 分支，您可以使用以下命令：

git checkout feature

这将切换到 feature 分支，并将工作目录中的文件更改为该分支的最新状态。
就比如我要切换到刚刚我创建的dev分支中。

另外我们发现切换分支之后，HEAD指向dev。

3.3 合并分支 和合并冲突

知道如何切换分支之后，我们来看看我们怎么合并分支，不过不能用简单的命令来。我用一个例子来说明。
我们在Dev环境中修改本地文件，然后再切换主节点，再次查看文件会发生什么，是同步还是不同步，让我们试试吧。

大家很明显可以看到，我在dev分支上更新的文件，并没有在master分支更新。为什么会出现这种现象呢？
大家可以查看dev和master分支指向。

这里明显可以看出指向操作是不一样的。状态图如下：

当切换到 master 分⽀之时，HEAD 就指向了 master，所以我们自然就看不见了。

说了为什么之后，我们就开始进行分支的合并操作。就是在master分支上看到Dev分支的内容了。

3.1 创建分支
要创建分支，您可以使用 git branch 命令。

git branch <branch_name>
例如，要创建一个名为 feature 的分支，您可以使用以下命令：

git branch feature
这将创建一个新的分支，并将其指向当前分支的最新提交。

3.2 切换分支
要切换分支，您可以使用 git checkout 命令。

git checkout <branch_name>
例如，要切换到 feature 分支，您可以使用以下命令：

git checkout feature
这将切换到 feature 分支，并将工作目录中的文件更改为该分支的最新状态。

3.3 合并分支
要合并分支，您可以使用 git merge 命令。

git merge <branch_name>

我们知道了什么命令之后，我们就开始操作。

之后，我们再来看一下状态图的变化。

上述这种情况只是一种情况，知识分支线有修改的情况下，但如果master和dev都同时修改了，我们再合并之后，会出现什么现象呢？大家不妨来操作一下。
在dev 的ReadMe的文件中增加 write bbb dev

在master 中增加 write bbb master

状态图如下：

然后我们开始合并操作

这时候我们就看到提示我们的合并冲突。
此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果！！

状态图如下：

3.4 删除分支

合并完成后, dev 分⽀对于我们来说就没⽤了， 那么dev分⽀就可以被删除掉。
注意:如果当前正处于某分⽀下，就不能删除当前分⽀.
要删除分支，您可以使用 git branch -d 命令。

git branch -d <branch_name>

状态图如下：

四.分支管理策略

分支管理策略是指在 Git 中使用分支的最佳实践。不同的项目有不同的需求，因此没有一种适合所有项目的分支管理策略。

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

我这里用具体的场景去分析分支管理策略。

第一种分支策略

例如我们现在正在 dev2 分支上进行开发，开发到一半，突然发现 master 分支上面有 bug，需要解决。可现在 dev2 的代码在工作区中开发了一半，还无法提交，怎么办?
例如：

我们的解决方案是：
在Git中，每个bug 都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
在开始解决bug之前Git 提供了 git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。

储藏 dev2 ⼯作区之后，由于我们要基于master分⽀修复 bug，所以需要切回 master 分⽀，再新
建临时分⽀来修复 bug，⽰例如下：

修复完成后，切换到 master 分⽀，并完成合并

最后删除分支：

合并工作完成后，我们的开发工作还要进行，这个时候，我们就需要把dev存在临时空间里面的内容取出来，继续开发。
我们使用 git stash pop 命令，恢复的同时会把 stash 也删了。

恢复完成之后，我们完成提交即可。

此时的状态变化图：

看着此时的状态变化图，我们注意到了，修复 bug 的内容，并没有在 dev2 上显示。
所以我们最终的目的还是要master分支和dev分支一起合并，前面我们介绍的要切换到master分支直接进行合并，但这样其实是有风险的。风险是什么，大家也很清楚，我们会引起合并冲突，而冲突需要我们手动修改代码。如果我们直接在maste分支上去修改，没有得到解决，就会导致错误出现在master分支上，后果不可设想，具体的状态图如下。

第二种分支策略

我们要解决上述这个问题，就开始了第二种分支策略，如何解决这个问题的方案如下：
第一步：自己的分支上合并下 master ，而不影响 master 。具体的分支图如下：

第二步:再让 master 去合并dev ，这样做的目的是有冲突可以在本地分⽀解决并进⾏测试。

具体的操作如下：
第一步：

第二步：

最后查看文件是否合并成功

总结

说了这么多，我们也到了分支管理首尾的时候了，大家一路走过来，发现了分支的作用了吗？要我说分支最大的作用就是分工，比如开发一个项目，你们如果在一个分支上面写，他就要等你写完，然后他才能写，有了分支之后，我们就可以多条线发展，你写你的，他写他的，互不干涉，直到开发完毕后，再一次性合并到原来的分支上，这样效率高，又不会影响整个项目的完成进度。