导航小助手
四、分支管理
4.1 管理分支
现在介绍一下Git的杀手级别功能之一：分支~
理解分支：
假设 主角A出生在一个 玄幻武侠村，村中现在正准备召开 武林大会，获胜者可赢取村长女儿~
此时，距离武林大会的召开 只剩下半年的时间；在这半年的时间里，A先练习基本功，之后学习降龙十八掌；同村的B 也准备参加武林大会，于是 B也跟着练习了起来；由于A、B天赋差不多，所以两个人对打获胜的几率是 五五开（B指代的是所有A的对手）~
然而，A身为主角，在练习基本功的时候，突然就觉醒了自身的天赋异能——多重影分身；于是 在本体练习降龙十八掌的时候，分身在练习金钟罩铁布衫......
半年时间匆匆而过，在比赛前夕，A收回分身，此时 再与B对战，胜率上升了不知道多少~
有图为证：
最终，A获得了武林大会的胜利，迎娶了村长的女儿~
作为Git，也有着 "多重影分身" 的功能：也可以分身，也可以合体~
在版本库里面，存在一个 HEAD指针，指向了master，master里面存储了最新一次提交的 commit id：
Git可以使用下面的命令，查看 最新提交的commit id 和 上一次提交的 commit id：
git cat-file -p 最新的commit id
有图示例：
当然，HEAD 不仅仅可以指向 master分支，也可以指向其他分支；而被指向的分支 就是当前正在工作的分支，即 add、commit操作 在该分支上提交的~
4.2 创建分支、切换分支、合并分支
Git提供了下面的命令，查看当前本地仓库中有哪些分支存在：
git branch
在 master 前面存在了一个 *，表示：目前 HEAD 正指向的是 master分支，master分支 就是当前正在工作的分支~
我们可以使用下面命令，来创建一个本地分支：
git branch 分支名称
此时，新创建的 dev分支 是基于当前最新版本上的创建的，所以 dev分支 也是指向的是 当前最新提交的~
验证：
一张图总结：
那么，我们怎么样使得 HEAD 指向新创建的 dev分支，让 dev分支 成为工作分支呢？
Git提供了如下的命令，用来 切换分支：
git checkout 所要切换到的分支名
验证：
此时，一张图总结：
当然，创建分支、切换分支 有两行命令，我们其实也可以用一行命令来达到相同的效果：
git branch 分支1
git checkout 分支1
上面两行代码，可以使用该代码进行替换：git checkout -b 分支1
此时，切换分支之后，就可以在 dev分支 上进行提交操作了~
此时，我们切换到 master分支之后，查看 ReadMe文件 内容，会发现 在 dev分支 上面新增的内容不见了：
此时，我们又切回到 dev分支 上，查看 ReadMe文件内容：
此时，我们再来看一下 dev分支 下面存储了啥 commit id，结果发现：和上次相比，commit id 变了：
此时，一张图总结（红色是master分支，绿色是dev分支）：
当最后切换到 master分支 的时候，看不见 dev分支 的提交也就变得很正常了~
为了在 master分支 上看见 dev分支 上所提交的内容，必须要进行 合并分支 的操作~
想让 master分支 合并 dev分支，必须要先切换到 master分支 上：
使用下面的命令，来进行分支的合并：
git merge 需要合并的分支
注意：意思是 当前的分支 合并 需要合并的分支 
此时，master分支 就合并 dev分支 成功：
此时，用一张图总结：
4.3 删除分支
需要注意的是，在删除分支的时候，必须是在其他的分支上删除~
即：想要删除 dev分支，可以在 master分支 上删除但是不可以在 dev分支 上删除 dev分支~
删除分支的命令是：
git branch -d 所要删除的分支
此时，用一张图总结：
因为 创建、合并、删除分支 非常快，所以 Git 鼓励使用某一个分支完成某一个任务，合并之后再删除分支，这和直接在 master分支 上面的工作效果是一样的，但是过程更加安全~
4.4 合并冲突
其实，在合并分支的时候，并不是说想合并就可以合并成功的~
在有的时候，合并分支 会发生冲突的情况~
比如说，现在有一 ReadMe文件，文件中内容：aaa on dev branch 没有满足需求，现在需要先创建一个本地分支div1，在此分支下修改成：bbb on dev branch；但是，与此同时 master分支 在 div1分支 修改 ReadMe文件 的时候，也对 ReadMe文件 进行了修改——"ccc on dev branch"~
在这种情况下，Git 在合并分支的时候并不会知道需要保留的是哪份内容，此时就会出现 "合并冲突"问题~
准备工作：
处理 div1分支 上面的问题：
处理 master分支 上面的问题：
此时，用一张图来表示当前的状态：
此时，如果合并分支的话，就会出现合并冲突：
发现合并冲突后，可以直接查看文件内容：
之后，可以根据自己的需求，来手动保留所需要的代码：
在修复完冲突之后，还需要进行一次提交操作：
此时本地仓库的状态：
进行提交操作之后：
此时仓库的状态：
此时，用一张图来表示：
最后，不要忘记了，div1分支 使用过后就可以删除了：
4.5 分支管理策略
场景一：ff模式
实际上，我们可以使用下面的命令 来查看图示效果：
git log --graph --abbrev-commit
实际上，使用了 Fast-forword模式 合并分支的时候，在删除分支之后，观察分支历史时，会丢掉分支信息；即 看不出来到底是 master分支 正常提交的，还是 其他的分支 merge 合并进来提交的~
此时，用一张图片总结 Fast-forword模式（ff） 提交的：
如果使用 no-ff模式的话，那么 在合并分支的时候，应该使用下面的命令：
git merge --no-ff -m "message" 所要合并的分支名
注意：message 指的是 描述，因为 no-ff模式 合并后会创建一个 commit，所以需要 -m 和 "message"此时，用一张图片总结 不是使用 Fast-forword模式（no-ff） 提交的：
4.5.1 分支策略
master分支 必须是非常稳定的~
用一张图来总结：
4.6 bug分支
虽然说，线上环境 是稳定的环境；但是 这其实并不是 100% 的稳定：比如说，平常使用的一些 app 也会出现卡死的情况~
那么，在修复 bug 的情况下，肯定是不可以在 master分支 上修复的；我们需要新建一个 bug分支，来专门处理 bug~
现在有这么一个场景：假设现在正在 dev3分支 中开发，开发到一半，还没有提交，发现 master分支 上面出现了 bug~
此时，需要使用到下面的命令：
git stash
注意：该命令表示 将工作区中的内容进行储存，存储到了 ./git 里面的 stash里面，当然 存储的是已经被 Git追踪管理的文件，即 add、commit过了
如果没有被 Git 追踪管理，那么就肯定存储不了：
此时，就可以创建一个修复bug的分支了；由于是基于 master分支 修复 bug，所以还需要切换到 master分支 上：
此时的状态就是：bug修复了，但是还没有合并到 master分支 上~
此时，就可以观察结果了：
由于 bug 已经修复，但是 dev3 还在开发当中，所以还需要切换到 dev3分支 上进行各种操作：
此时需要恢复存储区里面的内容：
git stash list
//查看 当前的 stash区 存储了哪些内容git stash pop
//将存储到 stash区 的内容放出来 
此时，再次查看 ReadMe文件 就可以了：
当然，由于 在 master分支 出现 bug 后提交的基础上创建了 dev3分支，但是 也不会影响 master分支~
最终的目的是让 master分支 合并 div3分支，但是 如果直接切回 master分支 合并的话，可能会出现合并冲突的问题~
这里就直接介绍一种比较好的方法：
第一步：
第二步：
最后，不要忘记删除分支，留下 master分支：
4.7 删除临时分支
在开发过程中，总是有无穷无尽的功能需要新增起来~
此时，有这样一个场景：产品经理 需要新增一个功能，在经过开发一天之后，在临时分支上 还没有 合并到 master分支上，产品经理 突然就说不要这个功能，需要把这个功能取消~
由于是在临时分支上进行操作的，所以还必须要把这个临时分支给删除~
上面曾介绍过一个删除分支的命令：
git branch -d 所要删除的分支实际上，这个命令 所要删除的分支 其实是已经进行了 merge操作，所以才可以进行删除；而在这种情况下，其实是删除不了的~
此时，只需要使用下面的命令即可强制删除：
git branch -D 所需要删除的分支演示：
此时，检查一遍即可：
791
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
