背景场景
在现代团队协作开发中，多分支并行开发是常态。通常，开发者会在独立的功能分支上完成编码，最终将变更集成到主干分支（如 main 或 master）。此时，Git 提供了两种主流方式来完成这一操作：merge 和 rebase。虽然二者都能实现代码合并，但其底层机制和最终提交历史结构存在本质区别。
初始环境搭建
假设项目初始化后默认存在一个主分支 master，并已完成一次初始化提交 C1。随后，在本地新增文件 a.txt 并提交，形成第二个提交 C2。此时将本地更改推送到远程仓库，主分支拥有两个连续的提交记录。
另一名开发者基于当前 master 分支创建功能分支 dev，并推送至远程。此后，该分支独立进行了三次提交：C3、C4、C5。与此同时，master 分支也由其他成员更新了一次，产生新提交 C6。此时两条分支的历史分叉开来，形成了典型的并行开发场景。
使用 merge 合并分支
当 dev 分支开发完成，需将其内容合并回 master 时，可执行以下命令：
git checkout master
git merge dev
该操作会触发以下流程：
- 查找两分支最近的共同祖先节点（本例中为 C2）
- 比较 dev 和 master 上自 C2 以来的所有变更
- 若存在冲突，则暂停合并过程，需手动解决后继续
- 生成一个新的合并提交 C7，包含来自 dev 的所有修改
最终提交历史呈现为非线性结构，清晰保留了分支演进路径。C7 提交有两个父提交：C6（原 master 最新）和 C5（dev 最新），体现了真正的"合并"行为。
使用 rebase 实现变基合并
另一种策略是采用 rebase 方式整合变更：
git checkout dev
git rebase master
此命令的作用是：
- 暂时移除 dev 分支上自 C2 起的提交（C3~C5）
- 将这些更改以补丁形式依次应用到 master 当前最新提交 C6 之后
- 生成三个全新的提交 C3'、C4'、C5'，内容相同但 SHA-1 哈希值不同
- 使 dev 分支指针指向新的提交链末端
完成后切换至 master 并执行 fast-forward 合并即可完成集成：
git checkout master
git merge dev
此时提交历史呈完全线性排列，无明显合并节点，看起来像是所有更改都按时间顺序依次完成。
核心差异对比
| 特性 |
merge |
rebase |
| 提交历史结构 |
保留分叉，体现真实协作过程 |
线性化历史，更整洁直观 |
| 提交对象是否改变 |
不改变原有提交 |
重写提交，生成新哈希 |
| 操作安全性 |
安全，适合公共分支 |
重写历史，不应在共享分支使用 |
| 调试追溯能力 |
强，保留原始上下文 |
弱，可能丢失原始提交信息 |
适用场景建议
- 优先使用 merge：在正式项目中，尤其是涉及多人协作的长期分支或发布分支，应使用 merge 来保持历史完整性。
- 选择性使用 rebase：适用于本地短期功能分支，在推送前整理提交历史，使其更清晰后再提交到主干。
需要注意的是，rebase 本质上是重写提交历史的操作，一旦对已公开的分支执行 rebase 并强制推送，可能导致协作者工作区混乱，因此必须谨慎使用。
