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

这样做的好处是:
第一步就算合并时出现了问题也可以在本地的dev分支下多次修改测试,不会影响master分支的代码

第二步时由于冲突在dev分支中就被解决了,那么此次合并基本就不会出现冲突问题了

4.合并冲突

我们开始第一步:
因为我们工作区的代码还没有add 和commit
所以要先add commit
然后merge

然后我们开始解决冲突

然后add commit

第一步完成
开始第二步:
切换到mater合并dev分支


至此bug问题成功解决

五.分支管理的小结

以上就是Git原理与使用(二):分支管理的全部内容,希望对大家有所帮助!