【Git：分支管理】Git 分支管理完全指南：从创建、合并到冲突解决

🔥艾莉丝努力练剑：个人主页

❄专栏传送门：《C语言》、《数据结构与算法》、C/C++干货分享&学习过程记录、Linux操作系统编程详解、笔试/面试常见算法：从基础到进阶、测试开发要点全知道

⭐️为天地立心，为生民立命，为往圣继绝学，为万世开太平

🎬艾莉丝的简介：

艾莉丝的Gitee地址

[1 ~> 理解分支](#1 ~> 理解分支)

[2 ~> 创建分支](#2 ~> 创建分支)

[3 ~> 切换分支](#3 ~> 切换分支)

[4 ~> 合并分支](#4 ~> 合并分支)

[5 ~> 删除分支](#5 ~> 删除分支)

[6 ~> 合并冲突](#6 ~> 合并冲突)

[7 ~> 分支管理策略](#7 ~> 分支管理策略)

[8 ~> 分支策略](#8 ~> 分支策略)

[9 ~> Bug分支](#9 ~> Bug分支)

[10 ~> 删除临时分支](#10 ~> 删除临时分支)

[11 ~> 分支管理部分小结](#11 ~> 分支管理部分小结)

Git：分支管理部分博主手记

结尾

艾莉丝的Gitee地址

艾莉丝努力练剑的gitee

1 ~> 理解分支

本章开始介绍Git的杀手级功能之一（这里注意是"之一"哦！也就是后面还有之二，之三......）：分支。分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习C++的时候，另一个你正在另一个平行宇宙里努力学习 JAVA。

如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并
了，结果，你既学会了C++又学会了JAVA！

这句话可能现在还没办法理解，等大家学习完本文的内容之后，一定能有所感悟。

在前面的【Git基本操作】的版本回退部分中，我们已经知道：每次提交，Git都把它们串成一条时间线，这条时间线就可以理解为是一个分支。截止目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支（主分支）。

通过一个小故事来理解一下分支的概念------

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

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

通过查看当前的版本库，我们也能清晰地理出思路：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ cat .git/HEAD 
ref: refs/heads/master
hyb@139-159-150-152:~/gitcode$ cat .git/refs/heads/master 
5476bdeb12510f7cd72ac4766db7988925ebd302

2 ~> 创建分支

Git支持我们查看或创建其他分支，这里我们来创建自己的第一个分支dev，对应的命令为：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git branch #查看当前本地所有分⽀
* master
hyb@139-159-150-152:~/gitcode$ git branch dev #新建分⽀dev
hyb@139-159-150-152:~/gitcode$ git branch
 dev
* master

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ ls .git/refs/heads/
dev master
hyb@139-159-150-152:~/gitcode$ cat .git/refs/heads/*
5476bdeb12510f7cd72ac4766db7988925ebd302
5476bdeb12510f7cd72ac4766db7988925ebd302

目前dev和master指向同一个修改。并且也可以验证下HEAD目前是指向master的。

cpp 复制代码

hyb@139-159-150-152:~/gitcode$ cat .git/HEAD
ref: refs/heads/master

总结一下------

3 ~> 切换分支

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout dev
Switched to branch 'dev'
hyb@139-159-150-152:~/gitcode$ git branch
* dev
 master
hyb@139-159-150-152:~/gitcode$ cat .git/HEAD
ref: refs/heads/dev

我们发现：HEAD已经指向了dev------表示我们已经成功的切换到了dev上！

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch 
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev 3740dce] modify ReadMe
 1 file changed, 1 insertion(+)

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout dev 
Switched to branch 'dev'
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

在dev分支上，内容还在------为什么会出现这个现象呢？

我们来看看dev分支和master分支指向，发现两者指向的提交是不一样的：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ cat .git/refs/heads/dev
bdaf528ffbb8e05aee34d37685408f0e315e31a4
hyb@139-159-150-152:~/gitcode$ cat .git/refs/heads/master 
5476bdeb12510f7cd72ac4766db7988925ebd302

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

当切换到master分支之时，HEAD就指向了master，当然看不到提交了！

4 ~> 合并分支

为了在master主分支上能看到新的提交，就需要将dev分支合并到master分支，示例如下：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git branch 
* dev
 master
hyb@139-159-150-152:~/gitcode$ git checkout master # 切换到 master 上进⾏合并
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git merge dev # 合并 dev 分⽀ 
Updating 16623e1..3740dce
Fast-forward
 ReadMe | 1 +
 1 file changed, 1 insertion(+)
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

git merge命令用于合并指定分支到当前分支。合并后，master就能看到dev分支提交的内容了。此时的状态如图如下所示。

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

5 ~> 删除分支

合并完成后，dev分支对于我们来说就没用了，那么dev分支就可以被删除掉。

**注意：**如果当前正处于某分支下，就不能删除当前分支，举个例子------

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git branch
* dev
 master
hyb@139-159-150-152:~/gitcode$ git branch -d dev 
error: Cannot delete branch 'dev' checked out at '/home/hyb/gitcode'

可以在其他分支下删除当前分支，比如------

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git branch -d dev 
Deleted branch dev (was bdaf528).
hyb@139-159-150-152:~/gitcode$ git branch
* master

此时分支的状态如图如下所示------

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

6 ~> 合并冲突

在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。
为了演示这问题，我们再创建一个新的分支dev1，并切换至目标分支，我们可以使用命令：

bash 复制代码

git checkout -b dev1

一步完成创建并切换的动作，示例如下：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout -b dev1
Switched to a new branch 'dev1'
hyb@139-159-150-152:~/gitcode$ git branch
* dev1
 master

在dev1分支下修改ReadMe文件 ，更改文件内容如下所示，并进行一次提交，如：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch # 将 aaa 该为 bbb
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev1 0854245] modify ReadMe
 1 file changed, 1 insertion(+), 1 deletion(-)

切换至master分支，观察ReadMe文件内容：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

我们发现：切回来之后，文件内容又变成了老的版本，这种现象很正常，我们现在也完全能理解。
此时在master分支上，我们对ReadMe文件再进行一次修改，并进行提交，如下：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git branch 
 dev1
* master
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write ccc for new branch 
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[master c10f6d0] modify ReadMe
 1 file changed, 1 insertion(+), 1 deletion(-)

现在，master分支和devi分支各自都分别有新的提交，此时状态如下所示------

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git merge dev1 
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
hyb@139-159-150-152:~/gitcode$ git status
On branch master
You have unmerged paths.
 (fix conflicts and run "git commit")
 (use "git merge --abort" to abort the merge)
Unmerged paths:
 (use "git add <file>..." to mark resolution)
 both modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")

我们发现ReadMe文件有冲突后，可以直接查看文件内容，Git会用**<<<<<<<，=======，>>>>>>>**来标记出不同分支的冲突内容，如下所示------

bash 复制代码

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
<<<<<<< HEAD
write ccc for new branch 
=======
write bbb for new branch 
>>>>>>> dev1

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch 
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"merge ReadMe"
[master 2976afc] merge ReadMe

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

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

bash 复制代码

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

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git branch 
* master
hyb@139-159-150-152:~/gitcode$ git branch -d dev1 
Deleted branch dev1 (was c594fd1).

7 ~> 分支管理策略

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

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

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

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

bash 复制代码

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，并切换至新的分支：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout -b dev2
Switched to a new branch 'dev2'

修改ReadMe文件，并提交一个新的commit：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev2 41b082f] modify ReadMe
 1 file changed, 1 insertion(+)

切回master分支，开始合并：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m "merge with no-ff" dev2
Merge made by the 'recursive' strategy.
 ReadMe | 1 +
 1 file changed, 1 insertion(+)
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d

请注意--no-ff参数，表示禁用Fast forward模式。

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

合并后，查看分支历史：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
* 5bd16b4 (HEAD -> master) merge with no-ff
|\ 
| * 41b082f (dev2) modify ReadMe
|/

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

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

8 ~> 分支策略

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

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

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

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

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

9 ~> Bug分支

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

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git branch 
* dev2
 master
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
i am coding ...
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git restore <file>..." to discard changes in working directory)
 modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git stash
Saved working directory and index state WIP on dev2: 41b082f modify ReadMe
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean

用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout master # 切回master
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git checkout -b fix_bug # 新建并切换到 fix_bug 分
⽀
Switched to a new branch 'fix_bug'
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e # 修复bug--忘记写e
hyb@139-159-150-152:~/gitcode$ git add ReadMe # 重新add，commit
hyb@139-159-150-152:~/gitcode$ git commit -m"fix bug"
[fix_bug 4bbc0c4] fix bug
 1 file changed, 1 insertion(+), 1 deletion(-)

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m"merge fix_bug branch" 
fix_bug 
Merge made by the 'recursive' strategy.
ReadMe | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
hyb@139-159-150-152:~/gitcode$ git branch -d fix_bug 
Deleted branch fix_bug (was 4bbc0c4).

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git checkout dev2 
Switched to branch 'dev2'
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git stash list
stash@{0}: WIP on dev2: 41b082f modify ReadMe

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git stash pop
On branch dev2
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git restore <file>..." to discard changes in working directory)
 modified: ReadMe
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (4f873250b3503687b5efd26196776aee7e3724c2

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

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git stash list
hyb@139-159-150-152:~/gitcode$

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

你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令git stash apply stash@[0}，这部分请uu们自行使用。

恢复完代码之后我们便可以继续完成开发，开发完成后便可以进行提交，例如：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
i am coding ... Done!
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev2 ed0916d] modify ReadMe
 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模式后得出的，主要是为了方便解释问题。

bash 复制代码

# dev 合并 master
hyb@139-159-150-152:~/gitcode$ git branch 
* dev2
 master
hyb@139-159-150-152:~/gitcode$ git merge master 
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
# 发⽣冲突
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
<<<<<<< HEAD
a,b,c,d
i am coding ... Done!
=======
a,b,c,d,e
>>>>>>> master
# 解决冲突并重新提交
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
i am coding ... Done!
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"merge master"
[dev2 447d29f] merge master
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean
# 切回master
hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
# master 合并 dev2---⽆需解决冲突！！
hyb@139-159-150-152:~/gitcode$ git merge dev2 
Updating 193421f..447d29f
Fast-forward
 ReadMe | 1 +
 1 file changed, 1 insertion(+)
 hyb@139-159-150-152:~/gitcode$ git status
On branch master
nothing to commit, working tree clean
# 删除 dev2 分⽀
hyb@139-159-150-152:~/gitcode$ git branch -d dev2 
Deleted branch dev2 (was 447d29f).

10 ~> 删除临时分支

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

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

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

bash 复制代码

# 新增并切换到 dev3 分⽀
hyb@139-159-150-152:~/gitcode$ git checkout -b dev3
Switched to a new branch 'dev3'
# 开始开发新功能并提交
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
i am coding ... Done!
i am writing new features ...
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe for new features"
[dev3 cd2f149] modify ReadMe for new features
 1 file changed, 1 insertion(+)
# 此时新功能叫停 
# 切回master准备删除dev3
hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
# 常规删除dev3分⽀时失败
hyb@139-159-150-152:~/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'.

直接使用传统的删除分支的方法不行，按照提示，才有了如下方式：

bash 复制代码

hyb@139-159-150-152:~/gitcode$ git branch -D dev3 
Deleted branch dev3 (was cd2f149).
hyb@139-159-150-152:~/gitcode$ git branch 
* master

11 ~> 分支管理部分小结

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

现在有了分支，就不用怕了。你创建一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样既安全又不影响别人工作。

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

Git：分支管理部分博主手记

结尾

创作过程中难免有所缺漏，如果uu们发现艾莉丝的文章哪里有所疏忽，望不吝赐教！感谢支持！

往期回顾：

【Git：基本操作】深度解析Git：从初始Git到熟悉基本操作

结语：都看到这里啦！那请大佬不要忘记给博主来个"一键四连"哦！

🗡博主在这里放了一只小狗，大家看完了摸摸小狗放松一下吧！🗡

૮₍ ˶ ˊ ᴥ ˋ˶₎ა