前言
文本将会向您介绍创建、查看、切换、合并、删除、合并、临时保存等分支管理操作
创建/查看/切换分支
[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 //切换分支
然后在dev分支上进行add，commit操作
[Fan_558@VM-12-13-centos gitcode]$ git checkout master //切换回master分支
原因是此时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分支上进行合并
小结
今天的分享就到这里啦，如果本文存在遗漏或错误的地方，还请您能够指出！
