【Git版本控制器--2】Git的分支管理
目录
理解分支
分支基本操作
合并冲突
合并模式
分支策略
强制删除分支
理解分支
master主分支
git中会保存每一次我们进行的提交，并把它们保存在对像区中！
如图所示的那条线，我们称他为提交时间线，也称之为主线
版本库中，有一个HEAD指针，HEAD指针指向了master指针。而master指针指向的是我们最新一次的提交的commit id。如下
所以提交时间线也被称为master主分支。因为我们只需要拿到master指针，就可以通过master指针找到最新一次的提交，通过最新一次的提交，我们可以拿到提交时间线中任意一次的提交
所以版本回退时，我们修改的是master指针的指向。如图中，假设我们改变master指针的指向为version2，那么version3(version2之后的提交)的commmit id我们无法获取
分支
git中，除了master分支(主分支)以外，允许我们进行创建分支与合并分支
我们可以在每一次提交之前或之后进行创建分支，在需要合并的地方进行合并分支！
我们可以在该分支中进行我们的开发操作，最后把该分支与主分支进行合并！
而接下来本文的重点是git的分支管理的理解(即what？why？how？)
为什么要有分支？
假设你和你们小组同事同时在master分支中进行开发，那么你的开发操作会导致工作区的内容被修改，从而影响你的同事
所以分支带来的第一个好处是支持你和你的同事对同一个项目可以进行并行开发！
我们写完了项目以后，是要进行发布的，当项目被发布了以后，跑的就是你master分支下的代码，如果你直接进行对master分支修改，那么会导致线上环境出现错误！
所以分支带来的第二个好处是支持开发和运行进行分离，开发人员可以在其他分支中大胆进行自己的开发操作，不用担心线上环境被影响！
当然，分支带来的好处不止这些，但这些是其中较为关键的好处！
分支基本操作
查看分支
查看当前分支：
git branch 
当前只有一条master分支
"*"的含义：前面带*的是我们的工作分支，如图中master分支就是我们现如今的工作分支
工作分支：HEAD指针不仅仅可以指向master分支，也可以指向其他的分支，而被HEAD指针所指的分支就是我们的工作分支，我们的add和commit操作...都是对工作分支的操作
创建分支
创建一个新的分支：
git branch [文件名] 
.git文件中的refs目录下保存了我们所创建的分支文件，并且新创建的分支文件中的初始内容是master分支的内容
可以对比一下我们之前的理解分支时的图，会发现是符合预期的！
切换工作分支
我们的目的是要创建完分支以后，在分支上进行开发操作的，所以我们需要把工作分支(HEAD指针的指向)切换到dev分支
切换分支：
git checkout [分支名] 
在刚创建分支时，分支的内容继承的是主分支的，但分支被创建出来以后，我们对分支的所有提交操作都不会再影响其他分支，如下示例
dev分支不会影响master分支，但如果我需要让master分支也能看到dev分支修改的代码如何做到呢？也就是如何合并分支！
合并分支
前提：若我们需要让dev分支的代码合并到master分支中，那么我们需要切换工作分支为master
合并分支：
git merge [分支名]
合并完成以后，master指针就指向了dev分支的最新一次提交
Fast-forward：快进模式，含义是把master指针指向了dev的最新一次提交
合并分支除了有快进模式以外，还会有其他模式！
删除分支
前提：删除一个分支的前提是你的当前工作分支必须不是你要删除的分支
删除分支：
git branch -d [分支名]
合并冲突
什么是合并冲突？
假设我们创建了一个dev分支，它里面有一个ReadMe文件，对dev分支中的ReadMe文件进行修改，添加了一行"aaa"，与此同时master分支也对自己中的ReadMe文件进行了修改，它添加了一行"bbb"。
对于上述情况，若我们把dev和master1进行分支合并到master中时，git无法得知应该怎么合并，因为dev和master1的修改都是开发人员做的，要保留哪些，去掉哪些都是开发人员决定的，而这种问题我们也称之为合并冲突问题
演示合并冲突问题
git除了会提示你合并冲突以外，还会对文件的内容进行修改，它会把冲突的内容直接都放到你的合并代码中，如下：
git虽然会把冲突内容写入到合并代码中，但它无法解决合并冲突问题，需要开发人员手动解决
如何解决合并冲突？
对于合并冲突问题，我们需要进行手动解决，即删除掉冲突的内容，之后再进行一次提交即可
合并冲突的图示
可以看到，解决了合并冲突并提交完成以后，master指针指向了最新一次提交，但dev指针仍然指向的是之前的提交。但当dev分支的内容被合并到master分支时，dev分支的使命也就完成了，直接删除掉dev分支就可以了
合并模式
首先，先进行一次合并分支我们看看现象
我们可以发现，快进模式下的Merge操作是没有标记此次提交是被merge的，而非快进模式下的Merge操作是标记出来了的！
正因如此，快进模式下的Merge操作在我们管理分支时可能会造成管理的不方便！因为我们无法分辨该提交是被master提交的还是被分支合并的
合并模式主要分为两种：
- fast-forward模式，简称ff模式，即快进模式
- no-fast-forward模式，简称no-ff模式，no-ff模式的合并会记录此次提交是被merge的还是被正常提交的！
合并时如何用no-ff模式提交
merge时的默认模式就是ff模式，若我们不想使用ff模式进行提交，那么我们需要在merge时带上选项，如下：
git merge --no-ff -m"[提交描述]" [分支名]
注意：由于我们不使用ff模式，那么master指针需要指向一个新的提交，我们需要跟commit一样描述此次提交
分支策略
master分支和其他分支
在企业开发时，git的分支管理通常遵循如下原则：
- master分支：master分支中的内容必须是稳定的，较少bug的
- 其他分支：是不稳定的，比起master分支来说允许有较多的bug
master分支中的内容一般是我们服务器给客户提供服务的内容，也就是说线上环境的服务，例如APP和网站都是在master分支上跑的，所以master分支必须是稳定的，无bug的
对于除master以外的分支，一般是我们开发人员在这些分支中进行开发操作，除master以外的分支最终是要被合并到master分支中的，这些分支中的内容可能存在bug。需要经过测试等流程以后才能正式被合并到master分支中
bug分支
master中给用户进行服务的代码也不一定是百分之百没bug的，可能会有用户运行期间产生的bug！
基于master分支代码可能存在bug的这个前提，如下场景：
假设你在一个分支(dev)中正在进行开发新功能的操作(还未进行提交)，而此时master分支中，发现了一个bug！你现在需要解决master分支中的这个bug，如何解决呢？
- 注意：千万不能在master分支上进行修复bug，因为开发人员可能会写出更大的bug，此时直接影响的是线上环境
- 注意：不能直接在dev分支中进行修复bug！
dev分支被创建的目的是开发新功能，而不是修复bug，如果直接在dev中进行修复bug，虽然也可以，但违背了dev分支被创建的初衷
你需要新建立一个分支(fix_bug)进行修复bug的操作，这个dev2分支就是专门用来解决bug的分支
当你再去解决bug之前，你需要把dev工作区的内容进行暂存，否则由于你的dev没有进行提交，你的开发操作在修复完bug后会找不到！
工作区内容暂存：
git stash工作区内容暂存的前提：git必须能够追踪管理你的开发文件，也就是说你的开发文件至少要有一次上传到本地仓库中
stash将工作区内容保存到哪了？
- 工作区内容被保存在.git/refs/stash中
将stash的代码进行恢复：
git stash pop查看stash存储了哪些代码
工作区内容暂存案例演示
不将当前工作区内容暂存，直接跑去别的进行开发的错误示范：
正确示范：
解决bug时的分支策略
首先，我们需要达到的一种状态是，dev分支正在进行开发操作，我们需要先解决master中的bug，所以重新创建一个fix_bug分支，进行bug修复，修复完bug以后，让bug分支与master分支进行合并，完成bug修复工作！也就是如下图
再之后的操作，即完成开发以后dev分支与master分支进行合并，第一种方式是把dev分支合并到master分支上
直接合并会带来合并冲突的问题，解决合并冲突需要手动解决，而手动解决就有可能会出现合并出错，由于线上环境运行的是master分支的内容，若出现合并出错是很严重的一个问题，所以我们不建议使用这种直接合并的方式
解决这个问题的⼀个好的建议就是：先把master分支的内容合并到dev分支下，此时虽然会发生合并冲突的情况，但我们也可以进行合并冲突，最关键的是dev分支是用于开发的，哪怕我们在这个分支下解决合并冲突出现问题，也能经过多次测试以后发现，还不会影响线上环境的运行！
之后再让master分支与dev分支解决完合并冲突的内容进行合并，由于dev分支已经解决了合并冲突问题，那么此次合并不再出现合并冲突问题
强制删除分支
若一个分支进行了提交以后，但还没有被合并。此时我们去删这个分支的时候，git不允许。于是在这种场景下，我们需要有方法可以强行删除这个分支！
强制删除分支：
git branch -D [分支名]