Merge Or Rebase

Merge Or Rebase

都具备分支间变更的能力：但是二者间实现手段大不相同

1. 实现手段

Merge（总是向前推进提交历史，并不会影响提交的原始状态）

我们在特性分支上，执行

# git 会以 我方、对方、以及双方最近公共祖先 对应的快照 ===> 执行三路合并生成新的快照
git merge master

三路合并生成新的快照

并基于此快照，创建一个连接 特性分支 feature 和 主干的合并节点

最后调整特性分支的指向

Rebase（整合变更，对提交历史进行重写）

我们在特性分支上，执行

# 1. git 会从双方最近的公共祖先开始，将特性分支每个提交对应的变更暂存起来，
# 2. 然后以主干分支指向的提交 为新起点，将暂存的变更按顺序，一一 还原成新提交
git rebase master

1. git 会从双方最近的公共祖先开始，将特性分支每个提交对应的变更暂存起来，
   
2. 然后以主干分支指向的提交 为新起点，将暂存的变更按顺序，一一 还原成新提交
   
   此时，特性分支的新起点，就像是从 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 处理已经被其它协作者引用的提交