Git 分支管理：从基础操作到协作流程（本地篇）
🔥草莓熊Lotso：个人主页
❄️个人专栏: 《C++知识分享》《Linux 入门到实践：零基础也能懂》
✨生活是默默的坚持，毅力是永久的享受！
🎬 博主简介：
文章目录
前言：
在 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]$ gitadd.[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify move.txt"[dev aee0d50] modify move.txt 1file 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 + 1file 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]$ gitadd.[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify move.txt"[dev1 3252095] modify move.txt 1file 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]$ gitadd.[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify move.txt"[master 800feaa] modify move.txt 1file 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]$ gitadd.[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]$ gitadd.[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify test.txt"[dev2 23e1ffd] modify test.txt 1file 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 + 1file 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]$ gitadd.[Lotso@VM-4-4-centos gitcode]$ git commit -m "fix bug"[fix_bug a5b2a26] fix bug 1file 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 +- 1file 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]$ gitadd.[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify"[dev2 8127dcc] modify 1file 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]$ gitadd.[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 + 1file 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]$ gitadd.[Lotso@VM-4-4-centos gitcode]$ git commit -m "modify new features"[dev3 c9bf49d] modify new features 1file 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 修复分支）、统一的合并策略，能让多人协作从 “代码混乱” 走向 “流程清晰”。记住，分支的本质是 “效率工具”，合理的分支管理不是增加开发负担，而是通过 “隔离” 与 “规范”，让代码迭代更高效、更可靠。
✨把这些内容吃透超牛的！放松下吧✨ʕ˘ᴥ˘ʔづきらど
