Git 分支管理：从基础操作到协作流程（本地篇）

🔥草莓熊Lotso： 个人主页
❄️个人专栏: 《C++知识分享》 《Linux 入门到实践：零基础也能懂》
✨生活是默默的坚持，毅力是永久的享受！

---

🎬 博主简介：

---

文章目录

• 前言：
• [一. 为什么需要分支？------ 分支的核心价值](#一. 为什么需要分支？—— 分支的核心价值)
• [二. Git 分支基础：核心概念与常用命令](#二. Git 分支基础：核心概念与常用命令)
• • [2.1 关键概念：分支与 HEAD 指针](#2.1 关键概念：分支与 HEAD 指针)
  • [2.2 基础命令：查看、创建、切换分支](#2.2 基础命令：查看、创建、切换分支)
• [三. 分支进阶操作：合并、删除和冲突](#三. 分支进阶操作：合并、删除和冲突)
• • [3.1 合并分支（`git merge`）：将分支代码融入目标分支](#3.1 合并分支（git merge）：将分支代码融入目标分支)
  • [3.2 删除分支（`git branch -d dev`）：在其它分支上进行删除当前分支](#3.2 删除分支（git branch -d dev）：在其它分支上进行删除当前分支)
  • [3.3 解决合并冲突：当代码修改重叠时](#3.3 解决合并冲突：当代码修改重叠时)
• [四. 分支管理规范：常见分支模型](#四. 分支管理规范：常见分支模型)
• • [4.1 合并分支的模式](#4.1 合并分支的模式)
  • [4.2 分支策略](#4.2 分支策略)
  • [4.3 bug 分支](#4.3 bug 分支)
  • [4.4 删除临时分支](#4.4 删除临时分支)
• 结尾：

---

前言：

在 Git 版本控制中，分支是实现 "并行开发""功能隔离""版本回溯" 的核心机制。无论是修复紧急 Bug、开发新功能，还是尝试实验性代码，合理的分支管理都能让代码迭代更有序、协作更高效。本文将聚焦 Git 分支的本地操作（不涉及远程仓库），从分支核心概念切入，详解分支创建、切换、合并、冲突解决等关键操作，帮你掌握 Git 分支管理的核心逻辑。

---

一. 为什么需要分支？------ 分支的核心价值

在未使用分支时，所有代码提交都会线性堆叠在 master 分支上，一旦出现问题（如开发中的功能影响线上代码、实验性代码失败），很难快速回滚或隔离风险。而分支的本质是 "代码版本的独立副本"，其核心价值体现在三点：

• 功能隔离：新功能（如 "支付模块"）在独立分支开发，不影响 master 分支的稳定性，开发完成后再合并；
• 并行开发：多人同时开发不同功能（A 开发登录、B 开发注册），各自在分支上提交，避免代码冲突；
• 风险控制：紧急 Bug 修复（如线上漏洞）可在单独的分支快速处理，无需等待未完成的功能开发。

分支就像是科幻电影里面的平行宇宙，当你正在电脑前努力学习 C++ 的时候，另⼀个你正在另⼀个平行宇宙里努力学习 JAVA。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了 C++ 又学会了 JAVA！

---

二. Git 分支基础：核心概念与常用命令

2.1 关键概念：分支与 HEAD 指针

• 分支本质 ：Git 分支并非复制完整代码目录，而是一个 "指向提交记录的指针"（占极少存储空间）。例如master分支指向最新的稳定提交，feature/login分支指向登录功能的最新提交；
• HEAD 指针 ：Git 用HEAD指针标记 "当前所在的分支"，执行git branch命令时，带*的分支即为HEAD指向的当前分支。

HEAD 严格来说不是指向提交，而是指向 master ,master 才是指向提交的，所以，HEAD 指向的就是当前分支。

每次提交，master 分支都会向前移动一步，这样，随着你不断提交，master 分支的线也越来越长，而 HEAD 只要一直指向 master 分支即可指向当前分支。
通过查看当前的版本库，我们能理清我们的思路：

[Lotso@VM-4-4-centos ~]$ cat .git/HEAD
ref: refs/heads/master
[Lotso@VM-4-4-centos ~]$ cat .git/refs/heads/master
9817f602e58a6c44d5ec63a23e0b38defe043080

2.2 基础命令：查看、创建、切换分支

（1）查看分支（git branch）

# 查看本地所有分支（* 表示当前分支）
[Lotso@VM-4-4-centos gitcode]$ git branch
* master

（2）创建分支（git branch <分支名>）

Git 支持我们查看或创建其它分支，创建分支时，Git 会基于 "当前分支的最新提交" 创建新指针，不会复制代码文件，在这里我们来创建第一个自己的分支 dev ，对应的命令为：

# 创建分支
[Lotso@VM-4-4-centos gitcode]$ git branch dev
[Lotso@VM-4-4-centos gitcode]$ git branch
  dev
* master

当我们创建新的分支后，Git新建了一个指针叫 dev ，* 表示当前 HEAD 指向的分支是 master 分支，另外，可以通过目录结构发现，新的 dev 分支：

[Lotso@VM-4-4-centos gitcode]$ ls .git/refs/heads/
dev  master
[Lotso@VM-4-4-centos gitcode]$ cat .git/refs/heads/*
7803308c167a495b3d18e6a3ba1cab43a9749872
7803308c167a495b3d18e6a3ba1cab43a9749872

我们会发现目前 dev 和 master 指向同一个修改。并且也可以验证 HEAD 目前是指向 master 的。

[Lotso@VM-4-4-centos gitcode]$ cat .git/HEAD
ref: refs/heads/master

一张图总结 ：

（3）切换分支（git checkout ）

那我们如何切换到 dev 分支下进行开发呢？使用 git checkout 命令即可完成切换，示例如下：

# 前提是 dev 分支已经通过 git branch 创建过了
[Lotso@VM-4-4-centos gitcode]$ git checkout dev
Switched to branch 'dev'
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev
  master
[Lotso@VM-4-4-centos gitcode]$ cat .git/HEAD
ref: refs/heads/dev

补充：创建并切换分支（一步操作）

[Lotso@VM-4-4-centos gitcode]$ git checkout -b dev
Switched to branch 'dev'
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev
  master

我们发现 HEAD 已经指向了 dev ，就表示我偶们已经成功切换到了 dev 上！

接下来，在 dev 分支下修改 move.txt 文件， 新增一行内容，并进行一次提交操作：

[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
[Lotso@VM-4-4-centos gitcode]$ echo "add branch1" >> move.txt
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
add branch1
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify move.txt"
[dev aee0d50] modify move.txt
 1 file changed, 1 insertion(+)

现在，dev 分支的工作完成，我们就可以切换回 master 分支：

[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world

切换回 master 分支后，发现 move.txt 文件中新增的内容不见了！！，赶紧切回 dev 看看

[Lotso@VM-4-4-centos gitcode]$ git checkout dev
Switched to branch 'dev'
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
add branch1

在 dev 分支上，内容还在。为什么会出现这个现象呢？我们来看看 dev 分支和 master 分支的指向，会发现两者的指向是不同的：

[Lotso@VM-4-4-centos gitcode]$ cat .git/refs/heads/dev
aee0d504f1435726a2e2a4187fdef061c8e87436
[Lotso@VM-4-4-centos gitcode]$ cat .git/refs/heads/master
7803308c167a495b3d18e6a3ba1cab43a9749872

看到这里大家应该就都明白了，因为我们是在 dev 分支上提交的，而 master 分支此刻的提交点并没有变，此时的状态如下图所示：

现在当切换到 master 分支后，HEAD 就直接指向 master 了，当然看不到提交了！

---

三. 分支进阶操作：合并、删除和冲突

分支开发完成后，需要将代码合并到目标分支；若合并时出现代码冲突，需手动解决；当然，删除分支也是必不可少的操作。

3.1 合并分支（git merge）：将分支代码融入目标分支

为了在 master 主分支上能看到新的提交，就需要将 dev 分支合并到 master 分支，合并分支的核心逻辑是 "将源分支的提交记录合并到目标分支"，需先切换到目标分支，再执行合并命令。

[Lotso@VM-4-4-centos gitcode]$ git branch
* dev
  master
[Lotso@VM-4-4-centos gitcode]$ git checkout master # 切换到 master 上进行合并
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ git merge dev # 合并 dev 分支
Updating 7803308..aee0d50
Fast-forward
 move.txt | 1 +
 1 file changed, 1 insertion(+)
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
add branch1

git merge 命令用于合并指定分支到当前分支。合并后，master 就能看到 dev 分支提交的内容

我们会看到上面合并之后，会出现 Fast-forward 代表 "快进模式"，也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。当然，也不是每次合并都能 Fast-forward，我们后面还没讲其它方式的合并。

3.2 删除分支（git branch -d dev）：在其它分支上进行删除当前分支

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

[Lotso@VM-4-4-centos gitcode]$ git branch
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev
  master
[Lotso@VM-4-4-centos gitcode]$ git branch -d dev
error: Cannot delete branch 'dev' checked out at '/home/Lotso/gitcode'

而可以在其它分支下删除当前分支，如：

[Lotso@VM-4-4-centos gitcode]$ git branch
  dev
* master
[Lotso@VM-4-4-centos gitcode]$ git branch -d dev
Deleted branch dev (was aee0d50).
[Lotso@VM-4-4-centos gitcode]$ git branch
* master

此时的状态如下图所示：

因为创建，合并，删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删除分支，这和直接在 master 分支上工作效果是一样的，但过程更安全。

3.3 解决合并冲突：当代码修改重叠时

若合并的两个分支修改了 "同一文件的同一部分" （如 master 分支和 dev 都修改了move.txt），Git 无法自动判断保留哪部分代码，会触发 "合并冲突" ，此时需手动解决。

为了演示这个问题，创建一个新的分支 dev1，并切换至目标分支，我们可以使用 git checkout -b dev1 一步完成创建并切换的动作，示例如下：

[Lotso@VM-4-4-centos gitcode]$ git checkout -b dev1
Switched to a new branch 'dev1'
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev1
  master

在 dev 分支下 修改 move.txt 文件 ，更改文件内容，并进行一次提交，如：

[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
add branch1
[Lotso@VM-4-4-centos gitcode]$ echo "bdd new branch" > move.txt # 将文件内容直接改成 bdd new branch
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
bdd new branch
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify move.txt"
[dev1 3252095] modify move.txt
 1 file changed, 1 insertion(+), 2 deletions(-)

切换至 master 分支 ，观察 move.txt 文件内容：

[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
hello world
add branch1

我们切换回来会发现文件内容还没变，这个我们上面讲过是因为还没提交，这个很好现在理解。那么我们此时如果在 move.txt 文件再进行一次修改，并进行提交，如下：

[Lotso@VM-4-4-centos gitcode]$ git branch
  dev1
* master
[Lotso@VM-4-4-centos gitcode]$ echo "cdd new branch" >move.txt
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
cdd new branch
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify move.txt"
[master 800feaa] modify move.txt
 1 file changed, 1 insertion(+), 2 deletions(-)

现在，master 分支和 dev1 分支都分别有了新的提交，变成了这样：

这种情况下，Git只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如下所示：

[Lotso@VM-4-4-centos gitcode]$ git merge dev1
Auto-merging move.txt
CONFLICT (content): Merge conflict in move.txt
Automatic merge failed; fix conflicts and then commit the result.
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch master
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#
# Unmerged paths:
#   (use "git add <file>..." to mark resolution)
#
#	both modified:      move.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

我们发现 move.txt 文件有冲突后，可以直接查看文件内容，要说的是 Git 会用 <<<<<<<, ======,>>>>>>> 来标记出不同分支的冲突内容，如下所示：

[Lotso@VM-4-4-centos gitcode]$ cat move.txt
<<<<<<< HEAD
cdd new branch
=======
bdd new branch
>>>>>>> dev1

此时我们需要手动调整冲突代码，并需要再次提交修正后的结果！！！(再次提交很重要，不要忘记)

[Lotso@VM-4-4-centos gitcode]$ nano move.txt
[Lotso@VM-4-4-centos gitcode]$ cat move.txt
bdd new branch
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "solve conflict"
[master cf9fd59] solve conflict

到这里冲突就解决完成，此时的状态变成了

我们使用带参数的 git log 也可以看到分支的合并情况，具体大家可以自行搜索 git log 的用法：

[Lotso@VM-4-4-centos gitcode]$ git log --graph --pretty=oneline --abbrev-commit
*   cf9fd59 solve conflict
|\  
| * 3252095 modify move.txt
* | 800feaa modify move.txt
|/  
* aee0d50 modify move.txt
* 7803308 move

最后，不要忘记 dev1 分支使用完毕后就可以删除了；

[Lotso@VM-4-4-centos gitcode]$ git branch
  dev1
* master
[Lotso@VM-4-4-centos gitcode]$ git branch -d dev1
Deleted branch dev1 (was 3252095).

---

四. 分支管理规范：常见分支模型

4.1 合并分支的模式

通常合并分支时，如果可能，Git会采用 Fast forward 模式，还记得如果我们采用 Fast forward 模式之后，形成的合并结果是什么呢？回顾一下

在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是merge进来的还是正常提交的。

但在合并冲突部分，我们也能看到通过解决冲突问题，会再进行下一次提交，得到的最终状态为：

那么这就不是 Fast forward 模式了。这样的好处时，从历史分支上就可以看出分支信息，例如我们现在已经删除了在合并冲突部分创建的 dev1 分支，但依旧能看到 master 其实是由其它分支合并得到：

hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe
|\ 
| * c594fd1 modify ReadMe
* | c10f6d0 modify ReadMe
|/

Git 支持我们强制禁用 Fast forward 模式，那么就会在 merge 时生成一个新的 commit，这样，从分支历史上就可以看出分支信息。

下面我们实战一下 --no-ff 方式的 git merge。首先，创建新的分支 dev2，并切换至新的分支：

[Lotso@VM-4-4-centos gitcode]$ git checkout -b dev2
Switched to a new branch 'dev2'

修改 test.txt 文件，并提交一个新的 commit

[Lotso@VM-4-4-centos gitcode]$ echo "a,b,c,d" > test.txt
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify test.txt"
[dev2 23e1ffd] modify test.txt
 1 file changed, 1 insertion(+)

切换回 master 分支，开始合并：

[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ git merge --no-ff -m"merge with no-ff"dev2
fatal: No commit specified and merge.defaultToUpstream not set.
[Lotso@VM-4-4-centos gitcode]$ git merge --no-ff -m"merge with no-ff" dev2
Merge made by the 'recursive' strategy.
 test.txt | 1 +
 1 file changed, 1 insertion(+)
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d

请注意 --no-ff 参数，表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建一个新的 commit ，所以加上 -m 参数，把描述写进去。

合并后，查看分支历史：

[Lotso@VM-4-4-centos gitcode]$ git log --graph --pretty=oneline --abbrev-commit
*   8de46c8 merge with no-ff
|\  
| * 23e1ffd modify test.txt
|/  

可以看到，不使用 Fast forward 模式，merge 后就像这样：

所以在合并分支时，加上 --no-ff 参数就可以普通合并模式，合并后的历史有分支，能看出曾经做过合并，而 Fast forward 合并后就看不出来曾经做过合并。

4.2 分支策略

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

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪里干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支上发布1.0版本；

你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

4.3 bug 分支

假如我们现在正在 dev2 分支上进行开发，开发到一半，突然发现 master 分支上面有 bug。需要解决。在 Git 中，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

可现在 dev 的代码在工作区中开发了一半，还无法提交，怎么办?例如：

[Lotso@VM-4-4-centos gitcode]$ git branch
* dev2
  master
[Lotso@VM-4-4-centos gitcode]$ echo "I am coding" >> test.txt
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d
I am coding
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch dev2
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   test.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

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

[Lotso@VM-4-4-centos gitcode]$ git stash
Saved working directory and index state WIP on dev2: 23e1ffd modify test.txt
HEAD is now at 23e1ffd modify test.txt
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch dev2
nothing to commit, working directory clean

再查看工作区，就是干劲的(除非有没有被Git管理的文件)，因此可以放心的创建分支来修复bug。

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

[Lotso@VM-4-4-centos gitcode]$ git checkout master  # 切回 master
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ git checkout -b fix_bug  # 新建并切换到 fix_bug 分支
Switched to a new branch 'fix_bug'
[Lotso@VM-4-4-centos gitcode]$ vim test.txt  # 修复bug，忘记写e了
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d,e
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "fix bug"
[fix_bug a5b2a26] fix bug
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到 master 分支，并完成合并，最后删除 fix_bug 分支：

[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'
[Lotso@VM-4-4-centos gitcode]$ git merge --no-ff -m "merge fix_bug branch" fix_bug
Merge made by the 'recursive' strategy.
 test.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d,e
[Lotso@VM-4-4-centos gitcode]$ git branch -d fix_bug
Deleted branch fix_bug (was a5b2a26).

至此，bug的修复工作已经做完了，我们还要继续回到 dev2 分支进行开发，切换回 dev2 分支：

[Lotso@VM-4-4-centos gitcode]$ git checkout dev2
Switched to branch 'dev2'
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch dev2
nothing to commit, working directory clean

工作区是干净的，刚才的工作存到哪里去了？用 git stash list 命令看看：

[Lotso@VM-4-4-centos gitcode]$ git stash list
stash@{0}: WIP on dev2: 23e1ffd modify test.txt

工作现场还在，Git把 stash 内容存在某个地方了，但是需要恢复一下，如果恢复现场呢？我们可以使用 git stash pop 命令，恢复的同时会把 stash 也删了，示例如下：

[Lotso@VM-4-4-centos gitcode]$ git stash pop
# On branch dev2
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   test.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (c769d0003e9603c79b9bbdf96586c6e645c5efb6)

再次查看的时候，我们已经发现没有现场可以恢复了

[Lotso@VM-4-4-centos gitcode]$ git stash list
[Lotso@VM-4-4-centos gitcode]$ 

另外，恢复现场也可以采用 git stash apply 恢复，但是恢复后，stash内容并不删除，你需要用 git stash drop 来删除；

你可以多次 stash，恢复的时候，先用 git stash list 查看，然后恢复指定的 stash ，用命令 git stash apply stash@{0} ，这部分大家可以自己去试试。

恢复完代码之后我们还可以继续完成开发，开发完后就可以提交了，例如：

[Lotso@VM-4-4-centos gitcode]$ vim test.txt
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d
I am coding...Done!
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify"
[dev2 8127dcc] modify
 1 file changed, 1 insertion(+)

但是我们注意到了，修复 bug 的内容，并没有在 dev2 上显示，此时的状态图为：

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

我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有⼀定风险的。

是因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。我们无法

保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，

有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。

此时的状态为：

解决这个问题的一个好的建议就是：最好在自己的分支上合并下 master ，再让 master 去合并 dev，这样做的目的是又冲突可以在本地解决并进行测试，而不影响 master。此时的状态为：

对应的实操演示如下，要说明的是，以下演示的merge操作，没有使用 --no-ff ，但上述的图示是禁用 Fast forward 了模式后得出的，主要为了方便解释问题。

# dev 合并 master
[Lotso@VM-4-4-centos gitcode]$ git branch
* dev2
  master
[Lotso@VM-4-4-centos gitcode]$ git merge master
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

# 发生冲突
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
<<<<<<< HEAD
a,b,c,d
I am coding...Done!
=======
a,b,c,d,e
>>>>>>> master

# 解决冲突并重新提交
[Lotso@VM-4-4-centos gitcode]$ vim test.txt
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d,e
I am coding...Done!
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "merge master"
[dev2 d07c456] merge master
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch dev2
nothing to commit, working directory clean

# 切回 master
[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'

# master 合并 dev2 ---无需解决冲突!!!
[Lotso@VM-4-4-centos gitcode]$ git merge dev2
Updating c8358de..d07c456
Fast-forward
 test.txt | 1 +
 1 file changed, 1 insertion(+)
[Lotso@VM-4-4-centos gitcode]$ git status
# On branch master
nothing to commit, working directory clean

# 删除 dev2 分支
[Lotso@VM-4-4-centos gitcode]$ git branch -d dev2
Deleted branch dev2 (was d07c456).

4.4 删除临时分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分支搞乱了，所以，每添加⼀个新功能，最好新建一个分支，我们可以将其称之为 feature 分支，在上面开发，完成后，合并，最后，删除该 feature 分支。

可是，如果我们今天正在某个 feature 分支上开发了⼀半，被产品经理突然叫停，说是要停止新功能的开发。虽然白干了，但是这个 feature 分支还是必须就地销毁，留着无用了。这时使用传统的 git branch -d 命令删除分支的方法是不行的。演示如下：

# 新增并切换到 dev3 分支
[Lotso@VM-4-4-centos gitcode]$ git checkout -b dev3
Switched to a new branch 'dev3'

# 开始开发新功能并提交
[Lotso@VM-4-4-centos gitcode]$ vim test.txt
[Lotso@VM-4-4-centos gitcode]$ cat test.txt
a,b,c,d,e
I am coding...Done!
I am writing new features......
[Lotso@VM-4-4-centos gitcode]$ git add .
[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify new features"
[dev3 c9bf49d] modify new features
 1 file changed, 1 insertion(+)

# 此时新功能叫停

# 切回 master 准备删除 dev3
[Lotso@VM-4-4-centos gitcode]$ git checkout master
Switched to branch 'master'

# 常规删除 dev3 分支时失败
[Lotso@VM-4-4-centos gitcode]$ git branch -d dev3
error: The branch 'dev3' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev3'.

直接使用传统的删除分支方式不行，按照提示，我们使用如下方式：

[Lotso@VM-4-4-centos gitcode]$ git branch -D dev3
Deleted branch dev3 (was c9bf49d).

小结 ：

分支在实际中有什么用呢？假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再⼀次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上

正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分支上，这样，既安全，又不影响别人工作。

并且 Git 无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

---

结尾：

🍓 我是草莓熊 Lotso！若这篇技术干货帮你打通了学习中的卡点：
👀 【关注】跟我一起深耕技术领域，从基础到进阶，见证每一次成长
❤️ 【点赞】让优质内容被更多人看见，让知识传递更有力量
⭐ 【收藏】把核心知识点、实战技巧存好，需要时直接查、随时用
💬 【评论】分享你的经验或疑问（比如曾踩过的技术坑？），一起交流避坑
🗳️ 【投票】用你的选择助力社区内容方向，告诉大家哪个技术点最该重点拆解
技术之路难免有困惑，但同行的人会让前进更有方向～愿我们都能在自己专注的领域里，一步步靠近心中的技术目标！

结语：Git 分支管理是版本控制的核心能力之一，它让我们在 "功能开发""Bug 修复""版本迭代" 中实现了高效的并行与隔离。从理解分支的 "指针本质"，到熟练运用git branch、git merge等命令完成分支的创建、切换与合并，再到掌握冲突解决的核心逻辑，每一步都是对 "代码迭代可控性" 的提升。而分支管理规范的价值，则体现在团队协作的 "有序性" 上 ------ 明确的分支模型（如功能分支、Bug 修复分支）、统一的合并策略，能让多人协作从 "代码混乱" 走向 "流程清晰"。记住，分支的本质是 "效率工具"，合理的分支管理不是增加开发负担，而是通过 "隔离" 与 "规范"，让代码迭代更高效、更可靠。

✨把这些内容吃透超牛的！放松下吧✨ ʕ˘ᴥ˘ʔ づきらど