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

Git原理与使用[二]:分支管理

一.分支的基本操作
二.合并分支
- 1.合并分支的基础操作
- 2.分支冲突
三.分支管理策略
四.创建临时分支修复bug
- [1.git stash存储工作区内容](#1.git stash存储工作区内容)
- 2.修复bug
- 3.删除临时分支
- 3.恢复工作区内容
- 4.合并冲突
五.分支管理的小结

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

一.分支的基本操作

1.理解分支

注意:

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

这就是master分支移动的大致草图

2.创建分支

既然分支这么强大,

那么我们如何创建分支呢?

bash 复制代码

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

默认情况下,我们只有master这一个分支

然后我们又创建了一个分支:dev

此时我们就有两个分支了

但是这个master分支前面为什么有一个*呢?

因为我们当前所在的分支是master分支

也就是HEAD目前正在指向的分支

那么怎么切换分支呢?

3.切换分支

bash 复制代码

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分支

bash 复制代码

git branch -d dev  删除dev分支

此时我处在dev分支下,因此无法删除dev分支

下面我切换到master分支再去删除dev分支

它提示我们:

当前分支还没有进行合并,无法删除

(关于分支合并的问题,我们接下来就会介绍)

如果你确定就是要删除这个分支

使用:

bash 复制代码

git branch -D dev

然后我们强制删除,此时删除成功

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

先创建分支,然后再去切换到该分支

操作略显冗余

那么可不可以创建并切换分支呢?

当然可以:

bash 复制代码

git checkout -b dev

二.合并分支

1.合并分支的基础操作

一般情况下

因为master分支相当重要,所以我们建议在dev分支上进行工作

最后只需要将dev分支上的内容合并到master分支当中即可

下面我们就在dev分支下修改一下test3.txt

并且add commit

bash 复制代码

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进来的还是正常提交的

在这里我们介绍一个命令

bash 复制代码

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,这样我们就能从分支历史上看出分支信息了

bash 复制代码

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提供了一个命令,可以将当前工作区的信息进行储藏,被储藏的内容可以在将来的某一个时间点恢复出来

cpp 复制代码

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分支进行开发

bash 复制代码

git stash list
查看存储的内容

bash 复制代码

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

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

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

我们在这里就使用git stash pop这个命令了