Git分支：是一种版本库管理与使用的方式；
场景：假设有一款软件上线运行了，线上版本为v5.0(活动版本)，开发版本(内部版本)到了dev5.5(统一为好多天的工作集合)，结果活动版本的充值系统出现了BUG，业务是活动充值打8折，结果玩家充值了100到账了80，而下一个线上版本为v6.0，现在急需修复BUG，上线v5.1；假设安排了员工1去修复BUG，该员工回滚到v5.0，然后修改BUG，并提交v5.1；但往后发展线上版本v6.0上线了，BUG在v6.0仍然存在。
将这一问题抽象为：版本库基本上都是线性发展的，但常会有一些额外的问题，需要从线性发展的过程中延伸其它的方向。
而Git软件正好就支持分支管理：创建分支版本库；支持各分支版本库之间的合并。
创建版本库之后，默认的分支是主分支-master；那么分支从哪儿来？从某一个版本而来，各分支向上追溯总会找到分界点(代码一样的时候)。
分支合并：当一个分支要被合并时，也就是说这个分支没有发展的必要了；切换到被合并的分支：master。但合并时可能存在一些问题(冲突)：
- 同一个文件，在不同的分支中有不同的变化：但是功能上没有冲突(两个分支修改的内容都要)；
- 同一个功能，写了两种方法。这是就要手动来解决冲突，即舍弃一种方法。
分支本质上是：在某一个节点，将版本库复制了一份，发展到不同的方向。
变基：顾名思义也就是改变基础。是一种将一系列提交从一个分支上重新应用到另一个分支上的操作。
如图：V3.1和Bug.1都是基于V3的，Bug.1用于修复V3中出现的bug，两条支线是同时进行的，也就是开发版本中，一直到V4发布，这个bug也依然是存在的，只有将修复bug的代码合并到V4(将bug版本的基础变为V4)，才能在线上版本中解决bug。将Bug.1分支的更改变基到V4上，意味着将bug修复的更改应用到V4的最新状态上，而不会产生额外的合并提交。这样，Bug.1分支的更改就会成为V4的一部分，而不需要在提交历史中显示为一个单独的合并操作。
