当前位置：首页 > news >正文

Git 第二讲---提高篇 git的分支管理

news 来源：原创 2025/5/14 9:15:26

前言：

在掌握了 Git 的基础操作（如提交、推送、拉取和合并）后，你已经迈入了版本控制的世界。然而，若想真正发挥 Git 的强大威力，成为高效协作的开发者，分支管理是必须跨越的关键门槛。

无论是个人项目还是团队协作，代码开发的场景往往充满复杂性：你可能需要同时尝试多个功能、紧急修复线上 Bug，或是在不干扰主代码的前提下进行实验性开发。此时，若将所有改动都堆积在一条主分支上，很快就会陷入混乱——代码冲突频发、版本难以追溯、功能耦合导致测试困难……

在本讲中，我们将深入 Git 分支管理的核心逻辑，解析 git branch、git checkout、git rebase 等命令的进阶用法，

接下来，让我们从一条简单的 git branch 命令开始，揭开高效开发的新篇章！

前言：

一、理解分⽀

二、分支操作初体验

2.1 创建分支

2.2 分支切换

2.3、合并分支

2.4、删除分支

三、合并分支冲突

四、分支模式与策略

4.1 分支模式

4.2 分支策略

五、Bug分支与删除临时分⽀

5.1 Bug分支的修复

5.2删除临时分⽀

总结：

一、理解分⽀

本章开始介绍 Git 的杀⼿级功能之⼀（注意是之⼀，也就是后⾯还有之⼆，之三……）

啥是分支？

分⽀就是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习 C++ 的时候，另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习 JAVA。如果两个平⾏宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平⾏宇宙合并了，结果，你既学会了 C++ ⼜学会了 JAVA！

在上一讲的版本回退⾥，我们已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即 master 分⽀。再来理解⼀下HEAD，HEAD 严格来说不是指向提交，⽽是指向master，master才是指向提交的，

所以HEAD 指向的就是当前分⽀，而当前分支才是指向的提交的修改id。

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

二、分支操作初体验

2.1 创建分支

Git ⽀持我们查看或创建其他分⽀，在这⾥我们来创建第⼀个⾃⼰的分⽀ dev ，对应的命令为：

git branch 【分支名】

上面的指令有两个作用 1.查看当前本地所有分⽀，2.带上分支名可以创建一个新分支。

我们发现打印出来的分支有的前面有“*”，这是表明当前用户是在那个分支。

另外，可以通过⽬录结构发现，新的 dev 分⽀：

发现⽬前 dev 和 master 指向同⼀个修改。并且也可以验证下 HEAD ⽬前是指向 master 的。

⼀张图总结：

2.2 分支切换

那如何切换到dev 分⽀下进⾏开发呢？使⽤ git checkout 命令即可完成切换，⽰例如下

我们发现 HEAD 已经指向了 dev，就表⽰我们已经成功的切换到了 dev 上！接下来，在 dev 分⽀下修改 ReadMe ⽂件，重复我们之前在master分支上进行的操作。

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

ReadMe文件内容：

hello hu
hello hu
hello V1
hello V2
hello V3

切换回 master 分⽀后，发现ReadMe⽂件中新增的内容不⻅了！！！赶紧再切回 dev 看看:

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

看到这⾥就能明⽩了，因为我们是在dev分⽀上提交的，⽽master分⽀此刻的提交点并没有变，此时的状态如图如下所⽰。

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

2.3、合并分支

我们创建出dev分支不只是简单的为了在该分支上执行操作，而是想要在该分支上进行修改，并且要反映到我们的master分支上。

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

注意：在git当中对某个分支进行操作的时候，是不能在该分支上操作的，所以我们的第一步是切换到其他的分支上。

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch
* devmaster
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout master
Switched to branch 'master'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git merge dev
Updating 10f4f59..43c9683
Fast-forwardReadMe | 2 ++1 file changed, 2 insertions(+)
admin@iZn4a2tqizasgm5y4xgt22Z:~$ cat ReadMe 
hello hu
hello hu
hello V1
hello V2
hello V3hello dev++

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

而在上面的合并过程中，打印出来的信息中有Fast-forward这又是啥呢？

Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。当然，也不是每次合并都能 Fast-forward，我们后⾯会在分支管理那部分讲其他⽅式的合并。

2.4、删除分支

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

注意：如果我们当前正处于某分⽀下，那我们就不能删除当前分⽀，如：

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branchdev
* master
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch -d master
error: Cannot delete branch 'master' checked out at '/home/admin'

⽽可以在其他分⽀下删除当前分⽀，如：

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch -d dev
Deleted branch dev (was 43c9683).
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch
* master

此时的状态如图如下所⽰。

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

我们在面对某个任务的时候一般是更推荐开创分支，在分支上进行操作，在分支上稳定后在合并分支，绝对不能在master分支上直接操作

三、合并分支冲突

可是，在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。为了演⽰这问题，创建⼀个新的分⽀ dev1 ，并切换⾄⽬标分⽀，我们可以使⽤ git checkout - b dev1 ⼀步完成创建并切换的动作，⽰例如下：

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch dev1
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout dev1
Switched to branch 'dev1'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ vim ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git add ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git commit -m "这是dev1的提交记录"
[dev1 bd96fe6] 这是dev1的提交记录1 file changed, 2 insertions(+)admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout master
Switched to branch 'master'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ vim ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git add ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git commit -m "这是为了演示合并冲突的代码"
[master d396e39] 这是为了演示合并冲突的代码1 file changed, 2 insertions(+)
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git log --preety=oneline
fatal: unrecognized argument: --preety=oneline
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git log --pretty=oneline
d396e3905b4ec70bd0a3d41daf57a0faadae7429 (HEAD -> master) 这是为了演示合并冲突的代码

在 dev1 分⽀下修改 ReadMe ⽂件，更改⽂件内容如下，并进⾏⼀次提交，切换⾄ master 分⽀

此时在 master 分⽀上，我们对 ReadMe ⽂件再进⾏⼀次修改，并进⾏提交。

现在， master 比特就业课分⽀和 dev1 分⽀各⾃都分别有新的提交，变成了这样：

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

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git merge dev1
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.

发现 ReadMe ⽂件有冲突后，可以直接查看⽂件内容，要说的是 Git 会⽤ >>>>>> ，=======，<<<<<<<<<来标记出不同分⽀的冲突内容，如下所⽰：


hello hu
hello hu
hello V1
hello V2
hello V3hello dev++<<<<<<< HEAD
hello master 演示合并搜索的情况
=======
hello dev1 world
>>>>>>> dev1

此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果！！（再次提交很重要，切勿忘记） ,你没有提交git是无法识别你有没有合并冲突的，也就无法保管这版本的文件。

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git add ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git commit -m "这次合并了分支，解决了两分支的冲突"
[master 955b12a] 这次合并了分支，解决了两分支的冲突
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git log --pretty=oneline
955b12a14ae5e78c940410d554a2fc23c19ce158 (HEAD -> master) 这次合并了分支，解决了两分支的冲突
d396e3905b4ec70bd0a3d41daf57a0faadae7429 这是为了演示合并冲突的代码
bd96fe665ea03dc32f27aa863200c0c66c8c8660 (dev1) 这是dev1的提交记录
43c9683040c5a40c55f0704f5757033c1354553f 这是在dev分支上的提交操作

到这⾥冲突就解决完成，此时的状态图变成了，同时也反映了为啥要再提交一次，不再提交，后面的新圆节点任何出现呢？

实际每次的状态分析我们不需要自己花，我们可以使用带参数的 git log也可以看到分⽀的合并情况，具体⼤家可以⾃⾏搜索 git log 的⽤法:

admin@iZn4a2tqizasgm5y4xgt22Z:~$  git log --graph --pretty=oneline --abbrev-commit
*   955b12a (HEAD -> master) 这次合并了分支，解决了两分支的冲突
|\  
| * bd96fe6 (dev1) 这是dev1的提交记录
* | d396e39 这是为了演示合并冲突的代码
|/  
* 43c9683 这是在dev分支上的提交操作
* 10f4f59 删除了文件三
* 4561e7d add v3
* aa12ee4 add v2
* 866b884 add v1
* f2e9b4e 这是提交的第二种情景
* 3605c60 这是模拟验证提交情景一

最后，不要忘记 dev1 分⽀使⽤完毕后就可以删除了

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch -d dev1 
Deleted branch dev1 (was bd96fe6).

四、分支模式与策略

4.1 分支模式

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

在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的。但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态为：

那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。

例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀，但依旧能看到 master 其实是由其他分⽀合并得到：【这种方式也被称为 no--ff方式】

admin@iZn4a2tqizasgm5y4xgt22Z:~$  git log --graph --pretty=oneline --abbrev-commit
*   955b12a (HEAD -> master) 这次合并了分支，解决了两分支的冲突
|\  
| * bd96fe6 (dev1) 这是dev1的提交记录
* | d396e39 这是为了演示合并冲突的代码
|/

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

下⾯我们实战⼀下 --no-ff ⽅式的 git merge 。

⾸先，创建新的分⽀ dev2 ，并切换⾄新的分⽀:

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch dev2
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout dev2
Switched to branch 'dev2'

修改 ReadMe ⽂件，并提交⼀个新的 commit :

admin@iZn4a2tqizasgm5y4xgt22Z:~$ vim ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git add ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git commit -m "这是dev2验证no--ff模式的提交"
[dev2 0870e75] 这是dev2验证no--ff模式的提交1 file changed, 1 insertion(+)

切回 master 分⽀，开始合并，合并后，查看分⽀历史：

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git merge --no-ff -m "使用no--ff模式合并" dev2
Merge made by the 'ort' strategy.ReadMe | 1 +1 file changed, 1 insertion(+)admin@iZn4a2tqizasgm5y4xgt22Z:~$ git log --pretty=oneline --graph
*   6818139ff1dfd1314ad83f0445d624518e421c81 (HEAD -> master) 使用no--ff模式合并
|\  
| * 0870e7521bd410ad47166bf08a16216b6b65c188 (dev2) 这是dev2验证no--ff模式的提交
|/  
*   955b12a14ae5e78c940410d554a2fc23c19ce158 这次合并了分支，解决了两分支的冲突
|\  
| * bd96fe665ea03dc32f27aa863200c0c66c8c8660 这是dev1的提交记录
* | d396e3905b4ec70bd0a3d41daf57a0faadae7429 这是为了演示合并冲突的代码
|/  
* 43c9683040c5a40c55f0704f5757033c1354553f 这是在dev分支上的提交操作

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

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

在实际编写项目的时候，我们是更推荐使用普通模式合并的。

4.2 分支策略

1）master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；

那在哪⼲活呢？

2）⼲活都在dev分⽀上，dev分⽀是不稳定的，属于测试环境。

⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布时，再把dev分⽀合并到master上，在master分⽀发布1.0版本；你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就可以了。

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

五、Bug分支与删除临时分⽀

5.1 Bug分支的修复

假如我们现在正在 dev2 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要解决。

在Git中，每个 bug 都一般是通过⼀个新的临时分⽀来修复而不是在对应分支上直接操作，修复后，合并分⽀，然后将临时分⽀删除。

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

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout dev2
Switched to branch 'dev2'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ vim ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ cat ReadMe 
hello hu
hello hu
hello V1
hello V2
hello V3hello dev++hello master 演示合并搜索的情况
hello dev1 world
hello dev2 world我现在正在对dev2代码进行开发，突然发现master的一个错误

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

打断，看到这里的小伙伴可能会有一些疑惑为啥不直接切换到master分支开始修复呢？

很简单，因为不保存工作区的内容就切换git分支，git会把未保存的工作区内容保留到新分支的工作区中。

//这是没有保存工作区，直接切换的文件内容admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout master
M	ReadMe
Switched to branch 'master'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ cat ReadMe 
hello hu
hello hu
hello V1
hello V2
hello V3hello dev++hello master 演示合并搜索的情况
hello dev1 world
hello dev2 world我现在正在对dev2代码进行开发，突然发现master的一个错误//保存过后
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git stash
Saved working directory and index state WIP on dev2: 0870e75 这是dev2验证no--ff模式的提交
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout master
Switched to branch 'master'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ cat ReadMe 
hello hu
hello hu
hello V1
hello V2
hello V3hello dev++hello master 演示合并搜索的情况
hello dev1 world
hello dev2 world
admin@iZn4a2tqizasgm5y4xgt22Z:~$ ^C

⽤ git status 查看⼯作区，就是⼲净的（除⾮有没有被 Git 管理的⽂件），因此可以放⼼地创建分⽀来修复bug。

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git status
On branch masternothing added to commit but untracked files present (use "git add" to track)

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

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout -b Bug
Switched to a new branch 'Bug'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ vim ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ cat ReadMe 
hello hu
hello hu
hello V1
hello V2
hello V3hello dev++hello master 演示合并搜索的情况
hello dev1 world
hello dev2 world模拟实现修复代码的步骤
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git add ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git commit -m "代码的Bug已经修复了"
[Bug 845850f] 代码的Bug已经修复了1 file changed, 2 insertions(+)

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

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout master
Switched to branch 'master'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git merge --no-ff Bug -m "这是模拟实现修复代码Bug的过程"
Merge made by the 'ort' strategy.ReadMe | 2 ++1 file changed, 2 insertions(+)
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch -d Bug
Deleted branch Bug (was 845850f).

⾄此，bug 的修复⼯作已经做完了，我们还要继续回到 dev2 分⽀进⾏开发。切换回 dev2 分⽀：

⼯作区是⼲净的，刚才的⼯作现场存到哪去了？⽤ git stash list 命令看看：

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout dev2
Switched to branch 'dev2'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ cat ReadMe 
hello hu
hello hu
hello V1
hello V2
hello V3hello dev++hello master 演示合并搜索的情况
hello dev1 world
hello dev2 world
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git stash list
stash@{0}: WIP on dev2: 0870e75 这是dev2验证no--ff模式的提交

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

admin@iZn4a2tqizasgm5y4xgt22Z:~$ 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:   ReadMeno changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (26ceb6755d3dd6d88441059cbf222f9e031a7edc)
admin@iZn4a2tqizasgm5y4xgt22Z:~$ cat ReadMe 
hello hu
hello hu
hello V1
hello V2
hello V3hello dev++hello master 演示合并搜索的情况
hello dev1 world
hello dev2 world我现在正在对dev2代码进行开发，突然发现master的一个错误

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

另外，恢复现场也可以采⽤ git stash apply 恢复，但是恢复后，stash内容并不删除，

你需要⽤ git stash drop 来删除；你可以多次stash，恢复的时候，先⽤ git stash list 查看，然后恢复指定的stash，⽤命令 git stash apply stash@{0} 。恢复完代码之后我们便可以继续完成开发，开发完成后便可以进⾏提交，例如：

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git add ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git commit -m "我们完成了代码的编写与修复"
[dev2 79be813] 我们完成了代码的编写与修复1 file changed, 2 insertions(+)

但我们注意到了，修复 bug 的内容，并没有在 dev2 上显⽰。

此时的状态图为：

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

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

是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。

我们⽆法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单，有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。

解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并 dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。

此时的状态为：

对应的实操演⽰如下，要说明的是，以下演⽰的merge操作，上述的图⽰是禁⽤ Fast forward 了模式后得出的，主要是为了⽅便解释问题。

1 这是在dev2上合并master分支admin@iZn4a2tqizasgm5y4xgt22Z:~$ git add ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git commit -m "我们完成了代码的编写与修复"
[dev2 79be813] 我们完成了代码的编写与修复1 file changed, 2 insertions(+)
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git merge master
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.2 发⽣冲突并解决了冲突
admin@iZn4a2tqizasgm5y4xgt22Z:~$ vim ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ cat ReadMe 
hello hu
hello hu
hello V1
hello V2
hello V3hello dev++hello master 演示合并搜索的情况
hello dev1 world
hello dev2 world我现在正在对dev2代码进行开发，突然发现master的一个错误
模拟实现修复代码的步骤3  解决冲突并重新提交admin@iZn4a2tqizasgm5y4xgt22Z:~$ git add ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git commit -m "这是第一步，在dev2上完成合并master操作"
[dev2 7683252] 这是第一步，在dev2上完成合并master操作4 切回masteradmin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout master
Switched to branch 'master'5 master 合并 dev2---⽆需解决冲突！！admin@iZn4a2tqizasgm5y4xgt22Z:~$ git merge --no-ff -m "完成了最后的合并操作" dev2
Merge made by the 'ort' strategy.ReadMe | 1 +1 file changed, 1 insertion(+)6 删除 dev2 分⽀admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch -d dev2
Deleted branch dev2 (was 7683252).
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch
* master
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git log --pretty=oneline --graph
*   cb2ad7f38fbe1691a75a98a29d39b3be6931600a (HEAD -> master) 完成了最后的合并操作
|\  
| *   7683252e2d0da808885e84f14f9099580f665ad5 这是第一步，在dev2上完成合并master操作
| |\  
| |/  
|/|   
* |   386fa77c5e7d22ff34c231f52acb823247c2285c 这是模拟实现修复代码Bug的过程
|\ \  
| * | 845850f77e669bd0c57275886bc7a8c11b4e5c7f 代码的Bug已经修复了
|/ /  
* |   6818139ff1dfd1314ad83f0445d624518e421c81 使用no--ff模式合并
|\ \  
| | * 79be8138437f1841ca1762c39fa3e92a4d38ff38 我们完成了代码的编写与修复
| |/  
| * 0870e7521bd410ad47166bf08a16216b6b65c188 这是dev2验证no--ff模式的提交
|/  
*   955b12a14ae5e78c940410d554a2fc23c19ce158 这次合并了分支，解决了两分支的冲突
|\  
| * bd96fe665ea03dc32f27aa863200c0c66c8c8660 这是dev1的提交记录
* | d396e3905b4ec70bd0a3d41daf57a0faadae7429 这是为了演示合并冲突的代码
|/

5.2删除临时分⽀

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

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

可是，如果我们今天正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功能的开发。

虽然⽩⼲了，但是这个 feature 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统的 git branch -d命令删除分⽀的⽅法是不⾏的。

演⽰如下：

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout -b dev3
Switched to a new branch 'dev3'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ vim ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git add ReadMe 
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git commit -m "我是一个很倒霉的程序员"
[dev3 591a9f1] 我是一个很倒霉的程序员1 file changed, 3 insertions(+)
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout master 
Switched to branch 'master'
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git checkout -b dev3
fatal: A branch named 'dev3' already exists.

直接使⽤传统的删除分⽀的⽅法不⾏，按照提⽰，有了如下⽅式:，直接带上-D选项直接删除。

admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch -D dev3
Deleted branch dev3 (was 591a9f1).
admin@iZn4a2tqizasgm5y4xgt22Z:~$ git branch
* master

总结：

分⽀在实际中有什么⽤呢？假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50% 的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。如果等代码全部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。现在有了分⽀，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分⽀上，这样，既安全，⼜不影响别⼈⼯作。在实际的代码开发中解决了许多的问题。

在下一讲中，我们将要真正的学习，git的远程操作，我们下期见！