你的功能分支落后于 main，而你需要新的改动。Git merge 与 rebase 就是获取这些改动的两种方式之间的选择，两者都是正确的，区别在于之后的历史长什么样。

我们建了一个很小的仓库，运行了两个命令，并把真实输出贴在下面，让你比较结果而不是凭空想象。刚接触 Git？请先看我们的 Git 入门教程（英文）。

git merge 和 git rebase 分别做什么

git merge 取两个分支的最新提交并把它们合并。如果两个分支都有新提交，Git 会创建一个有两个父提交的合并提交，已存在的内容不会被改动。

git rebase 取出你分支独有的提交，先放在一边，把你的分支移到另一个分支的最新提交上，然后逐个重放你的提交。被重放的提交是带有新哈希的新提交，尽管改动内容相同。

git merge 实战

起点如下：main 上有提交 A，feature 上有两个提交（F1、F2），之后 main 又多了一个提交（M1）。现在把 main 合并进 feature。

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

图中展示了真实的过程：两条工作线被合并在一起。原来的提交 F1 和 F2 保留各自的哈希。代价是多了一个合并提交，而在活跃的项目里，这张图会变成一张网。

git rebase 实战

起点相同，但这次我们把 feature 变基到 main 上。

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

历史成了一条直线，就像你是在 M1 之后才开始工作的。注意哈希：F1 原来是 5a71e3c，现在是 bf9149e；F2 从 082cc6a 变成了 1ff474b。Git 重写了它们，这就是 rebase 需要小心的原因。

merge 与 rebase 并排对比

rebase 的黄金法则

不要对存在于你自己仓库之外的提交做 rebase。rebase 之后，你的分支与服务器上的副本不再一致，所以推送需要强制。如果同事在旧提交的基础上做了工作，他们的历史就会与你的产生分歧，处理起来很痛苦。

对自己的私有功能分支做 rebase 没问题；对 main 或其他人在用的分支做则不行。

安全的团队工作流

这套流程能保持历史整洁，又不会让任何人意外。大多数团队在 CI 流水线前也这么做，例如我们的 GitHub Actions CI/CD 指南（英文）里的那个。

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

如果自上次 fetch 以来有人向服务器分支推送过，--force-with-lease 会拒绝覆盖它，而普通的 --force 会悄悄把它毁掉。拉取请求通过后，把它合并进 main。

如何撤销错误的 rebase

rebase 看起来有破坏性，但旧提交会在 Git 的 reflog 中保留一段时间，所以你可以退回去。

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

在任何有风险的 rebase 之前，用 git branch backup 创建一个备份分支，恢复就只需一条命令。旁边还要在容器里运行数据库或工具？请看我们的 Docker 入门教程（英文）。

总结

Merge 保留真相，rebase 保持整洁。用 rebase 刷新自己的分支，用 merge 交付它，并且永远不要改写别人依赖的历史。

常见问题

继续学习（英文文章）