Git分支管理

前言

文本将会向您介绍创建、查看、切换、合并、删除、合并、临时保存等分支管理操作

创建/查看/切换分支

[Fan_558@VM-12-13-centos gitcode]$ git branch dev   //创建分支
[Fan_558@VM-12-13-centos gitcode]$ git branch		//查看分支
  dev
* master
[Fan_558@VM-12-13-centos gitcode]$ git checkout dev //切换分支

当我们从master分支切换到dev分支并对Readme文件进行修改（添加了第6行）

在这里插入图片描述

然后在dev分支上进行add，commit操作

[Fan_558@VM-12-13-centos gitcode]$ git checkout master //切换回master分支

我们打印Readme文件后会发现master分支下的Readme内容并不和dev分支下的内容相同

在这里插入图片描述

原因是此时master分支并没有指向最新的提交

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

合并分支

因此我们需要将dev分支的内容合并到master分支上

在这里插入图片描述

最后我们再打印Readme文件，会发现此时master分支下也具有了dev分支上添加的内容
我们也可以观察二者指向的提交（此时一致了）

在这里插入图片描述

删除分支

合并完成后, dev 分⽀对于我们来说就没⽤了，那么dev分⽀就可以被删除掉，注意如果当前正处于某分⽀下，就不能删除当前分⽀，只能在其他分支上删除其他分支。

在这里插入图片描述

如果一个分支上进行了add，commit操作后，切回master分支想要删除这个分支，这时使⽤传统的 git branch -d 命令删除分支的方法是不行的

这时我们需要使用强制删除git branch -D dev

合并冲突

若是我们在dev分支做修改
在这里插入图片描述
又在master分支做了修改

并都进行add，commit操作
现在， master 分⽀和 dev1 分⽀各⾃都分别有新的提交

这种情况下，Git 只能试图把各⾃的修改合并起来，但这种合并就可能会有冲突
在master分支下尝试合并dev分支
发现 ReadMe ⽂件有冲突后，可以直接查看⽂件内容，要说的是 Git 会⽤ <<<<<<<，=======，来标记出不同分⽀的冲突内容
如下：
在这里插入图片描述
这时我们就需要手动进行修改，并需要再次提交修改后的结果
修改成如下：

注意一定重新提交

合并分支的两种模式

此前我们合并分支的方式是： git merge +分支这种合并的方式默认是Fast forward，在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的

在这里插入图片描述

我们可以观察到，add hello linux的那一行并没有显示该提交是我们合并还是直接commit得来的。

Git ⽀持我们强制禁⽤ Fast forward 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样，从分⽀历史上就可以看出分⽀信息。
–no-ff ⽅式的 git merge
在这里插入图片描述
当我们强制禁⽤ Fast forward 模式后，再合并，打印提交信息
可以观察到delete hello linux那一行，有合并的指向，告诉我们此提交是通过merge合并得来的

Stash临时保存修改

临时保存修改：当你正在进行一项工作，但需要暂时保存当前的修改，以便稍后继续工作时可以使用stash命令。这在你需要切换到其他任务或者处理突发情况时非常有用。当你正在一个分支上进行开发（I am coding...）时，这时候在master分支上发现了一个bug，我们需要修复这一个bug，然而结合我们之前所讲，在一个分支上做的修改需要在当前分支下进行add，commit操作，然而我们并没有完成开发，只是想要临时离开去修复一个bug，因此我们需要用stash命令对工作区的修改进行暂存

dev分支下：
在这里插入图片描述
进行git stash暂存修改操作

然后切换到fix_bug分支上修复bug

提交

将修复好的内容合并到master分支上

最后切回dev分支进行git stash pop将指定的暂存的修改恢复继续进行开发

最后再一次add，commit就好了，再切回master分支上进行合并