Git原理与使用(二):分支管理

分支管理是Git的杀手锏之一
威力无比强大
下面就让我们一起开始分支管理的探索之旅吧

一.分支的基本操作

1.理解分支

在这里插入图片描述
注意:

HEAD指向的是当前分支!!!

在这里插入图片描述
这就是master分支移动的大致草图

2.创建分支

既然分支这么强大,
那么我们如何创建分支呢?

git branch 查看当前本地的所有分支
git branch 分支名   创建分支

在这里插入图片描述
默认情况下,我们只有master这一个分支
然后我们又创建了一个分支:dev
此时我们就有两个分支了

但是这个master分支前面为什么有一个*呢?
因为我们当前所在的分支是master分支
也就是HEAD目前正在指向的分支

那么怎么切换分支呢?

3.切换分支

git checkout 分支名

熟悉不熟悉,git checkout – 文件名
撤销操作,回退工作区中的文件内容
此时它没有加--,就变成了切换分支的命令
在这里插入图片描述
创建分支就像是这样:

其实切换分支就是把HEAD指针改一下指向即可
因此切换分支就像是这样:

下面我们在dev分支上面修改test.txt这个文件(分身学习java)
然后看看会不会对master分支造成任何影响?
(在互相独立的平行空间当中,分身去学习java会不会让正在专心致志学习C++的我们感到疲惫?)
在这里插入图片描述
在dev分支上面修改了test.txt并进行了add和commit之后
我们回到master分支下看看test.txt有没有更新

然后我们发现对master分支并没有影响
(分身学java不会让我们感到疲惫,正和我们的需求)

dev分支上依然存在,分身会有java的知识
那么它是怎么做到的呢?
在这里插入图片描述
也就是这样:

4.删除分支

首先要说明的是:
1.如果我们当前正处于某分支下,就不能删除该分支只有当我们处于其他分支下的时候才可以删除该分支
2.因为master分支相当重要,所以谨慎期间我们一定不能删除master分支

git branch -d dev  删除dev分支

在这里插入图片描述
此时我处在dev分支下,因此无法删除dev分支
下面我切换到master分支再去删除dev分支

它提示我们:
当前分支还没有进行合并,无法删除
(关于分支合并的问题,我们接下来就会介绍)
如果你确定就是要删除这个分支
使用:

git branch -D dev

在这里插入图片描述
然后我们强制删除,此时删除成功

5.补充:创建并切换分支

先创建分支,然后再去切换到该分支
操作略显冗余
那么可不可以创建并切换分支呢?
当然可以:

git checkout -b dev

在这里插入图片描述

二.合并分支

1.合并分支的基础操作

一般情况下
因为master分支相当重要,所以我们建议在dev分支上进行工作
最后只需要将dev分支上的内容合并到master分支当中即可

下面我们就在dev分支下修改一下test3.txt
并且add commit
在这里插入图片描述

git merge 分支名

将某个分支中的内容合并到当前分支下
因此,我们需要先切换到master分支下,然后在master分支上面合并dev分支
在这里插入图片描述
合并成功,test3.txt的新版本也进入了master分支中的暂存区和版本库了

其中这个Fast-forward代表"快进模式"
也就是直接把master指向dev的当前提交,所以合并速度非常快
当然,不是每次合并都能够Fast-forward,我们后面会介绍其他方式的合并
在这里插入图片描述
这就是合并的过程:

2.分支冲突

但是在实际的分支合并的时候不是我们想合并就能合并成功的,有时候可能会遇到代码冲突的问题.
下面我们在dev分支下把test.txt的第二行给它修改一下
在这里插入图片描述
然后在dev分支下 add commit

然后我们切换到master分支下
一开始时master分支下的test.txt肯定是没有dev分支下添加的那一行的(这点我们现在也完全能够理解)
因此master分支下的那个人就继续往下写代码了

写完之后add commit

此时,master和dev分支都有了各自的新的提交,也就是变成了这样:
在这里插入图片描述
此时合并的话就可能会有冲突

然后我们切换到dev分支下合并master分支
因为master分支是主分支,相当重要,而dev分支则没有那么重要
因此我们不会让master分支出现任何"危险",要时刻保护master分支的安全

在这里插入图片描述
下面我们vim test.txt
看一下变成了什么样子

此时我们必须要手动调整冲突代码,并需要再次提交修正后的结果

最后我们修改成了这个样子,这个样子其实就是master分支修改后的内容
此时冲突就被解决了
然后我们还要add commit一下
在这里插入图片描述
然后git merge master就成功了

此时冲突解决完成
状态就变成了

三.分支管理策略

1.Fast-forward模式

通常合并分支时,如果可能的话,Git会采用Fast-forward模式
而在Fast-forward模式下我们是看不出该次提交时merge进来的还是正常提交的

在这里我们介绍一个命令

git log --graph --pretty=oneline --abbrev-commit

在这里插入图片描述
这个命令可以从分支历史上看出分支信息
也就是能够看出到底是merge进来的还是正常提交的

在合并冲突时进行合并的模式就不是Fast-forward了
因为Fast-forward模式是直接改变分支的指向的
而我们解决合并冲突时又进行了一次新的提交
最后在dev分支下进行merge合并时才让master分支指向那次新的提交

2.–no–ff(即:禁用Fast-forward模式)

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

git merge --no-ff -m "提交信息" 要合并的分支名称

下面我们来演示一下
我们切换到dev分支下往test.txt文件中再去新增一行内容
然后 add commit
然后切换到master分支下去合并dev分支
在这里插入图片描述

大家只需要知道:
1.禁用Fast-forward模式后合并时会创建一个新的commit id
所以要加上-m参数

2.在合并分支时加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并
但是Fast-forward就看不出曾经做过合并

3.分支策略

在这里插入图片描述

四.创建临时分支修复bug

在Git中,每一个bug都可以通过创建一个新的临时分支来修复.
修复后,合并分支,再把临时分支删除

1.git stash存储工作区内容

假如我们现在正在dev分支上进行开发,
开发到一半了,突然发现master分支上面有bug,需要解决
可是我现在dev分支上的代码在工作区写了一半了,还无法提交,怎么办呢?

例如:
我现在在test1.txt上面写了一些代码
在这里插入图片描述
Git提供了一个命令,可以将当前工作区的信息进行储藏,被储藏的内容可以在将来的某一个时间点恢复出来

git stash

在这里插入图片描述
目前我们的工作区就变成干净的了(除非我们工作区目前的文件还有没被Git管理的文件),因此我们就可以放心的创建分支来修复bug了

2.修复bug

因为bug出现在master分支上
所以我们要基于master分支创建临时分支来修复bug
在这里插入图片描述
然后在这个临时分支fix_bug上修复bug
假设test1.txt的第一行就是bug,这一行要改成写hello这五个字符

然后add commit 之后就修复完成了
然后切换到master分支完成合并

3.删除临时分支

合并完成之后,master分支上的bug就被修复成功了
然后我们就可以删除fix_bug分支了
在这里插入图片描述

3.恢复工作区内容

至此,bug的修复工作做完了,我们还要继续回到dev分支进行开发

git stash list
查看存储的内容

在这里插入图片描述

git stash pop
恢复工作区的内容,恢复的同时也会把stash的内容删除掉

也可以使用这个命令
git stash apply
恢复工作区的内容,恢复的同时并不会把stash的内容删除掉
需要使用git stash drop来删除

我们也可以使用git stash apply stash@{
    
    0}来恢复指定的stash内容

我们在这里就使用git stash pop这个命令了
在这里插入图片描述
但是此时我们修复bug后的内容并没有在dev分支上面显示
因此我们就要
1.在dev中合并master分支
2.在master分支下合并dev分支