Git 使用指南 --- 分支管理

BUG制造机.

于 2024-09-02 09:00:42 发布

阅读量360

点赞数 9

分类专栏： Git 使用指南文章标签： git linux 服务器

本文链接：https://blog.csdn.net/weixin_73757824/article/details/141788166

版权

Git 使用指南专栏收录该内容

2 篇文章 0 订阅

订阅专栏

序言

在这篇文章中，我们将介绍 Git 分⽀管理，从分⽀创建，切换，合并，删除的整个⽣命周期，灵活进⾏各种场景下的分⽀管理，学习常⻅分⽀管理策略。

1. 理解分支

想象一下，大学临近期末的你还是开学模样，后天就要考试了，但是你还没复习（准确地说还没开始😱）机组，计网，线代，马原…怎么办😭！你恨不得一分钟掰成两分钟用，恨不得创造几个分身帮你复习不同的科目，最后合并全部分身前去考试，那么压力就小不止一星半点！当然，你不可能做到，但是 Git 做到了😲！
使用 Git 创建分支并行开发，不仅大大的提高了开发的效率还隔离了风险，避免不稳定的代码直接进入 master，增加了主分支的风险。

2. 创建分支

那我们可以使用指令为 Git 创建一个分支（影分身）：

git branch [name]

之后我们可以使用指令来查看存在的所有分支以及当前我们处在哪个分支：

git branch

输入这段代码后显示以下内容：
在这里插入图片描述

3. 切换分支

如何切换到指定的分支下呢？只需要使用指令：

git checkout [name]

同时也可以是使用 git branch 来检查自己是否切换成功。

我们在这里验证一下上一篇文章我们得出的结论 — HEAD 指向当前正在工作的分支，上篇文章因为我们只包含一个分支 master，所以无法验证，现在我们处在 dev 分支下查看 HEAD：
在这里插入图片描述
可以观察到现在 HEAD 指向的是 dev，而不是 master。

现在我们进行如下操作：

在 dev 目录下往 readme 文件添加新的一行内容
将该文件进行添加以及提交操作，保存到 dev 的版本库
切回到 master 分支，查看 readme 文件的内容

将会出现以下现象：

在这里插入图片描述

为什么我更新的文件内容在 dev 分支下才可以显示呀，master 为什么没有呀？这是因为 新版的内容以及被 dev 分支所管理了，而 master 管理的是上一个版本的内容是不一样的!
口说无凭，我将向大家证明一下，大家还记得 master 保存的就是当前分支下最新的 commit id(版本)，同样的 dev 也是这个道理：
在这里插入图片描述
同时，我们对分支之间的关系也有了一个新的认识关系：

原来 HEAD 指向 dev 分支，自然可以看见修改的内容，现在 HEAD 指向 master 分支，肯定就看不见啦！

4. 合并分支

4.1 FF 快进模式

当我们的分支完成了我们交给他的任务，现在我们需要他合并到主分支，需要进行以下步骤：

切换到 master 分支
使用指令进行快速切换 git merge [name]
完成分支的合并

在这里向大家举个栗子，在主分支里我们有一个文件（已提交到版本库管理）包含以下内容：

1 read                                                                                                                                                                                                      X 
   1 How are you?

现在我们切换到 dev 分支写入内容：

 1 readme                                                                                                                                                                                                      X 
   1 How are you?
   2 I am fine!

同样的，我们也需要将修改后的版本提交到 dev 的版本库中进行管理。

现在我们使用合并分支的上述步骤，我们可以得到以下信息：
在这里插入图片描述
首先，可以直观地看到内容确实合并了，我们的目的达成了。其次，这里的 Fast-forward 代表 快进模式，所谓快进模式就是 直接把 master 指向 dev 的当前提交。使用图像来描述就是这样：

在这里插入图片描述
ff模式(快进模式)虽然简便，但是存在不少缺点其中有一个就是：快进合并通过将 目标分支的指针直接移动到源分支的最新提交上，从而简化了分支历史。然而，这种简化可能过于激进，导致合并的历史信息丢失。

4.2 NO-FF 非快进模式

为了解决 FF模式 带来的缺陷，我们可以在合并时使用选项来禁用该模式，这个新的模式本质是创建一次新的提交，Git 会为这个将合并后的结果视为一个新的版本：
在这里插入图片描述
指令为：

git merge --no-ff -m "Your_msg" [name]

5. 合并冲突

在实际进行分支合并时，不是那么简单的，分支冲突是时常发生的，就比如再上一个例子中，我们只是在 dev 分支下对 readme 文件进行了修改，万一我的 master 分支同时也对该文件进行了相应的修改呢?
在 dev 分支下我的文件内容如下：

 1 readme                                                                                                                                                                                                      X 
   1 How are you?
   2 I am fine!

而在 master 分支下我的文件内容如下：

 1 readme                                                                                                                                                                                                      X 
   1 How are you?
   2 I am not fine, QAQ！

现在我们再一次使用合并操作，得到以下信息：
在这里插入图片描述
这个信息告诉我们这里起冲突了，需要我们手动解决冲突，现在我们再次打开文件 readme：

1 readme                                                                                                                                                                                                       X 
   1 How are you?
   2 <<<<<<< HEAD
   3 I am not fine, QAQ!
   4 =======
   5 I am fine!
   6 >>>>>>> dev

现在他向我们标注出了冲突部分，并且需要我们自己决定需要保留那一部分，我在这里删除掉 dev 的部分，保留 master 的内容！
请记住，在解决冲突之后，还需要我们进行手动提交！！！

6. 删除分支

当一个分支的内容被合并之后，它的任务也就达成了，自然而然也该退出了，在这里删除分支的指令为：

git branch -d [name]

但是请注意，不能处于当前分支上删除当前分支！

7. Bug 分支场景

当你在 dev 分支上进行功能开发时，突然 master 分支上的程序在运行时出现了 Bug。这时，通常解决的解决方案是，建立一个临时用来修复 Bug 的分支。
但是我在当前分支下的代码还没写到 1 / 4 呢，怎么办呢？我们可以使用 git stash 命令将当前工作区的信息进行存储起来，当以后需要时再复原。
Bug 修复好了，我回来了，我们可以使用指令 git stash list 来查看我们存储的信息，之后可以使用指令 git stash pop 将我们的信息恢复到当前工作区下。