Merge Or Rebase
都具备分支间变更的能力：但是二者间实现手段大不相同
1. 实现手段
Merge（总是向前推进提交历史，并不会影响提交的原始状态）
我们在特性分支上，执行
# git 会以 我方、对方、以及双方最近公共祖先 对应的快照 ===> 执行三路合并生成新的快照
git merge master
三路合并生成新的快照
并基于此快照，创建一个连接 特性分支 feature 和 主干的合并节点
最后调整特性分支的指向
Rebase（整合变更，对提交历史进行重写）
我们在特性分支上，执行
# 1. git 会从双方最近的公共祖先开始，将特性分支每个提交对应的变更暂存起来，
# 2. 然后以主干分支指向的提交 为新起点，将暂存的变更按顺序，一一 还原成新提交
git rebase master
- git 会从双方最近的公共祖先开始，将特性分支每个提交对应的变更暂存起来，
- 然后以主干分支指向的提交 为新起点，将暂存的变更按顺序，一一 还原成新提交
此时，特性分支的新起点，就像是从 C1 迁移到了 C6
2. 异同点
同
内容完全一致
异
二者却构建出了迥异的提交的历史
3. 日常开发中经常遇到的例子【开发者从 feature 发起 PR】
由于 master 分支也合入了新的提交，在 PR 中显示，feature 分支和主干间存在冲突而无法合并，此时开发者通常有2 种方式解决冲突问题
将 master 分支 merge 到 feature 分支，并在合并时解决冲突
这样做会在方法方法会在 feature 分支中引入一个合并提交（包含解决冲突所做的修改）
将 feature 分支 rebase 到 master 的最新提交，并在 rebase 过程中解决冲突
4. 交互式 Rebase【提交的重排、压缩、拆分、丢弃】
git rebase -i master
顺序调整
squash 命令（实现对提交的压缩）
drop 指令
5. rebase -i 综合应用
6. 注意点
Git rebase 在重设基线，修整历史的过程中，会产生新的提交替换老提交，谨记：
千万不要使用 rebase 处理已经被其它协作者引用的提交
