Rebase vs Merge
在日常的开发中，对接合并分支，有两种方式 merge 和 rebase，但在很多时候，我们却只使用merge，对于rebase的使用上缺乏使用经验，今天有时间就尝试下学习下rebase和merge的具体差异性
概念
Merge（合并）
Merge 是将两个分支的历史记录合并在一起，生成一个新的"合并提交"(merge commit)，保留两个分支的完整历史
git checkout dev_my
git merge dev
Rebase（变基）
Rebase 是将当前分支的提交"重新播放"到目标分支的最新提交之上，重写提交历史，使历史记录呈现线性
# 将dev_my的修改变基到dev上
git checkout dev_my
git rebase dev
主要差异
| 特性 | Merge | Rebase |
|---|---|---|
| 历史记录 | 保留分支结构，显示分叉和合并 | 线性历史，隐藏分支操作 |
| 提交数量 | 增加一个合并提交 | 不增加额外提交 |
| 冲突处理 | 一次性解决所有冲突 | 可能需要多次解决冲突 |
| 适用场景 | 公共分支 | 本地分支/功能开发分支 |
| 安全性 | 安全，不重写历史 | 重写历史，需谨慎使用 |
| 可视化效果 | 显示分支结构 | 显示线性历史 |
工作流程比较
Merge 工作流程
使用merge会出现一条新的commit记录
A---B---C feature
/ \
D---E---F-----------G master (合并后)
Rebase 工作流程
使用rebase会将commit线保持线性状态，不会出现的新的commit记录，但会出现时间错乱问题，即是commit线并不是按照时间线排序的
A---B---C feature
/
D---E---F---A'---B'---C' master (变基后)
使用场景建议
使用 Merge 的情况
- 合并公共分支（如 master/main 到你的分支）
- 需要保留完整的分支历史
- 团队协作中多人使用的分支
使用 Rebase 的情况
- 整理本地提交历史
- 将功能分支更新到主分支最新状态
- 准备合并前清理提交历史
在大多数现代工作流中，推荐的做法是：
- 在功能分支上使用 rebase 保持与主分支同步
该步骤对应的操作即是，自己在自己的dev分支开发，而公共的dev已经出现了新的提交，可以使用rebase合并dev分支，来保证自己的分支是处在最新的状态，同时也是处在自己分支的最前端展示
- 最后使用 merge 将功能分支合并到主分支
冲突处理
Merge
在merge阶段出现冲突后，只需要处理冲突，然后 git add 后 重新commit即可
Rebase
在rebase阶段出现冲突，需要一个个节点上处理冲突，在处理完冲突后，使用 git add 提交修改后的文件，然后执行 git rebase --continue 来处理下一个节点，一层层处理
