前言：
在之前，我们已经对分支的基本操作以及对合并分支中遇到的问题进行了解决。接下来，我将给大家介绍的是关于 分支管理策略 的问题。
（一）分支管理
通常合并分⽀时，如果可能，Git 会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast
forward 模式之后，形成的合并结果是什么呢？
- 回顾⼀下：
在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提
交到底是 merge 进来的还是正常提交的。
但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态为：
那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。
- 例如我 们现在已经删除了在合并冲突部分创建的 dev1 分⽀，但依旧能看到 master 其实是由其他分⽀合并得到：
Git ⽀持我们强制禁⽤ Fast forward 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样，
从分⽀历史上就可以看出分⽀信息。
下⾯我们实战⼀下 --no-ff ⽅式的 git merge
- ⾸先，创建新的分⽀ dev2 ，并切换⾄新的分⽀:
- 修改 Test ⽂件，并提交⼀个新的 commit
- 切回 master 分⽀，开始合并:
【说明】
- 请注意 --no-ff 参数，表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创建 ⼀个新的 commit ，所以加上 -m 参数，把描述写进去。
- 合并后，查看分⽀历史：
- 可以看到，不使⽤ Fast forward 模式，merge后就像这样
所以在合并分⽀时，加上 --no-ff 参数就可以⽤普通模式合并，合并后的历史有分⽀，能看出来曾
经做过合并，⽽ fast forward 合并就看不出来曾经做过合并。
1、分⽀策略
在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：
- ⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；
- 那在哪⼲活呢？⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布 时，再把dev分⽀合并到master上，在master分⽀发布1.0版本；
- 你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就 可以了。
所以，团队合作的分⽀看起来就像这样：
总的策略如下：
（二）bug 分⽀
假如我们现在正在 dev2 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要
解决。在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除。
可现在 dev2 的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？例如：
- Git 提供了 git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来
【说明】
- ⽤ git status 查看⼯作区，就是⼲净的（除⾮有没有被 Git 管理的⽂件），因此可以放⼼地创建分⽀来修复bug。
- 接下来我们看一下保存的信息到此保存到哪了：
- 储藏 dev2 ⼯作区之后，由于我们要基于master分⽀修复 bug，所以需要切回 master 分⽀，再新建临时分⽀来修复 bug，⽰例如下：
- 修复完成后，切换到 master 分⽀，并完成合并，最后删除 fix_bug 分⽀：
- ⾄此，bug 的修复⼯作已经做完了，我们还要继续回到 dev2 分⽀进⾏开发。切换回 dev2 分⽀：
- ⼯作区是⼲净的，刚才的⼯作现场存到哪去了？⽤ git stash list 命令看看：
- ⼯作现场还在，Git 把 stash 内容存在某个地⽅了，但是需要恢复⼀下，如何恢复现场呢？我们可以使⽤ git stash pop 命令，恢复的同时会把 stash 也删了，⽰例如下：
- 再次查看的时候，我们已经发现已经没有现场可以恢复了
【说明】
- 另外，恢复现场也可以采⽤ git stash apply 恢复，但是恢复后，stash内容并不删除，你需要 ⽤ git stash drop 来删除；
- 你可以多次stash，恢复的时候，先⽤ git stash list 查看，然后恢复指定的stash，⽤命令 git stash apply stash@{0}
- 恢复完代码之后我们便可以继续完成开发，开发完成后便可以进⾏提交，例如：
- 但我们注意到了，修复 bug 的内容，并没有在 dev2 上显⽰。此时的状态图为：
Master 分⽀⽬前最新的提交，是要领先于新建 dev2 时基于的 master 分⽀的提交的，所以我们
在 dev2 中当然看不⻅修复 bug 的相关代码。
我们的最终⽬的是要让 master 合并 dev2 分⽀的，那么正常情况下我们切回 master 分⽀直接合
并即可，但这样其实是有⼀定⻛险的。
是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。我们⽆法 保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单， 有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。 此时的状态为：
解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并
dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。此时的状态
为：
对应的实操演⽰如下，要说明的是，以下演⽰的merge操作，没有使⽤ --no-ff ，但上述的图⽰是
禁⽤ Fast forward 了模式后得出的，主要是为了⽅便解释问题。
- dev 合并 master
- 发⽣冲突
- 解决冲突并重新提交
- 切回master
- master 合并 dev2---⽆需解决冲突
- 删除 dev2 和 fix_bug 分⽀
（三）删除临时分⽀
软件开发中，总有⽆穷⽆尽的新的功能要不断添加进来。
添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分⽀搞乱了，所以，每添加⼀个新 功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，合并，最
后，删除该 feature 分⽀。
可是，如果我们今天正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功
能的开发。虽然⽩⼲了，但是这个 feature 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统
的 git branch -d 命令删除分⽀的⽅法是不⾏的。演⽰如下：
- 新增并切换到 dev3 分⽀
- 切回master准备删除dev3
- 直接使⽤传统的删除分⽀的⽅法不⾏，按照提⽰，有了如下⽅式:
总结
分⽀在实际中有什么⽤呢？
- 假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50% 的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。如果等代码全 部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。
- 现在有了分⽀，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上 正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的⽀ 上，这样，既安全，⼜不影响别⼈⼯作。
- 并且 Git ⽆论创建、切换和删除分⽀，Git在1秒钟之内就能完成！⽆论你的版本库是1个⽂件还是1万个⽂件。
以上就是关于分支管理的全部内容了。感谢大家的观看与支持！！！
