Merge vs. Rebase

日期: 2025年8月5日

引言：问题的起源

今天遇到了一个经典的 Git 工作流问题：在使用 git pull 从远程仓库拉取更新时，默认行为会创建“合并提交”（Merge Commit），导致主干分支（如 master 或 main）的提交历史变得非线性、复杂且难以追溯。这引出了关于 merge 和 rebase 两种不同工作流的深入探讨。

一、git pull 的两种核心模式

git pull 命令本质上是 git fetch（拉取）和另一个命令的组合。

1. 默认模式：git pull (等同于 git fetch + git merge)

• 工作原理：获取远程更新后，将远程分支的更改以“合并”的方式应用到当前本地分支，并生成一个“合并提交”。
• 优点：
  • 忠实记录历史：完整保留了分支合并的全部信息，忠实反映了“在某个时间点，集成了另一个分支的开发成果”这一事实。
  • 非破坏性：只新增提交，不修改原有提交历史，对新手更安全。
• 缺点：
  • 历史非线性：频繁拉取会产生大量合并节点，使 git log --graph 的输出像一张复杂的蜘蛛网，难以阅读。

2. 推荐模式：git pull --rebase

• 工作原理：获取远程更新后，将你本地的、尚未推送到远程的提交“拎起来”，先让本地分支与远程分支同步，然后再将你的提交逐个“重新应用”（replay）在最新代码的顶端。
• 优点：
  • 线性历史：提交历史是一条干净的直线，非常清晰易读。
  • 避免无意义的合并提交。
• 缺点：
  • 重写历史：rebase 会改变你的本地提交哈希值（Commit Hash），是一种破坏性操作。
• 一劳永逸的配置：

  # 将 rebase 设置为 git pull 的默认行为
  git config --global pull.rebase true
  
  # 如果需要处理本地未提交的更改，可以配置 autostash
  git config --global rebase.autostash true

二、"圣战"：Rebase 与 Merge 的哲学之争

选择哪种模式并非技术上的对错，而是两种开发哲学的较量。

特性	Rebase 派 (追求线性历史)	Merge 派 (追求真实历史)
核心理念	提交历史应该像一本清晰的书，易于阅读和理解。	提交历史应该像一份法庭记录，忠实、完整且不可篡改。
历史形态	干净的单一直线。	带有分叉和合并节点的图谱。
优点	- 易于追溯单个变更<br>- git bisect排错更方便<br>- Code Review 更清晰	- 保留完整的上下文<br>- 一键可回滚整个特性<br>- 更安全，不修改历史
适用场景	个人分支同步主干、团队追求清晰的提交线。	多人协作的大型项目、强调历史不可变性的团队。

三、黄金实践：合并前变基 (Rebase Before Merge)

这是解决个人特性分支与主干分支冲突的最佳实践，它结合了 rebase 和 merge 的优点。

场景：我的特性分支 feature/login 落后于 main 分支，且存在冲突。

目标：在发起合并请求（Pull Request）前，以最干净的方式解决冲突。

操作步骤：

1. 切换到特性分支

   git checkout feature/login

2. 获取远程最新代码

   git fetch origin

3. 将当前分支变基到最新的主干分支上

   git rebase origin/main

4. 循环解决冲突 (如果 rebase 过程中出现冲突)
   • 根据提示，手动修改冲突文件。
   • 保存文件后，执行 git add <resolved-file>。
   • 继续 rebase 进程：git rebase --continue。
   • (若想放弃，可随时 git rebase --abort 返回原状态)。
5. 推送更新后的特性分支 由于 rebase 重写了历史，需要强制推送。使用 --force-with-lease 更安全，它能防止覆盖掉别人在你推送期间提交的新代码。

   git push origin feature/login --force-with-lease

最终收益：

• 冲突在个人分支内部被完美解决。
• 提交到 main 分支的 Pull Request 可以被无冲突地、以“快进”（Fast-Forward）模式合并。
• main 分支的历史永远保持整洁的线性。

四、核心原则与注意事项

1. Rebase 的黄金法则：永远不要对一个已经推送到远程并被多人使用的公共分支（如 master, develop）执行 rebase 操作！ 这会给其他协作者带来灾难。Rebase 主要用于整理个人分支的历史。
2. 变基前的状态：执行 rebase 前，工作区必须是干净的（没有未提交的更改）。可以使用 git stash 暂存更改，或使用 autostash 配置自动处理。