带你解析git的基础功能(二)
文章目录
- 一.前言
- 二.什么是git的分支管理
- 三.git的分支管理的相关操作
-
- 3.1 创建分支
- 3.2 切换分支
- 3.3 合并分支 和合并冲突
- 3.4 删除分支
- 四.分支管理策略
-
- 第一种分支策略
- 第二种分支策略
- 总结
一.前言
掌握 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
例如，要创建一个名为 feature 的分支，您可以使用以下命令：
git branch feature
这将创建一个新的分支，并将其指向当前分支的最新提交。
3.2 切换分支
要切换分支，您可以使用 git checkout 命令。
git checkout
例如，要切换到 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 ，这样做的目的是有冲突可以在本地分⽀解决并进⾏测试。
具体的操作如下：
第一步：
第二步：
最后查看文件是否合并成功
总结
说了这么多，我们也到了分支管理首尾的时候了，大家一路走过来，发现了分支的作用了吗？要我说分支最大的作用就是分工，比如开发一个项目，你们如果在一个分支上面写，他就要等你写完，然后他才能写，有了分支之后，我们就可以多条线发展，你写你的，他写他的，互不干涉，直到开发完毕后，再一次性合并到原来的分支上，这样效率高，又不会影响整个项目的完成进度。