Git Rebase vs Merge
最后更新
git merge 和 git rebase 都能把一个分支的工作整合到另一个分支。git merge 用一个合并提交把两段历史连在一起，原样保留发生过的一切。git rebase 则把你的提交逐个重放到另一个分支之上，得到干净的线性历史，但在这个过程中会改写你的提交。
黄金法则：永远不要对别人已经拉取的提交执行变基。在终端在线编辑器中把两种方式都试一试，浏览器里就是真正的 shell。
并排对比
| 特性 | git merge | git rebase |
|---|---|---|
| 历史形状 | 有分叉，带合并提交 | 线性 |
| 改写提交 | 否 | 是 |
| 在共享分支上安全 | 是 | 否 |
| 原样保留历史 | 是 | 否 |
| 容易追溯何时合并 | 是 | 较难 |
语法
| 命令 | 作用 |
|---|---|
git merge feature | 把 feature 合并到当前分支 |
git merge --no-ff feature | 始终创建合并提交 |
git rebase main | 把当前分支的提交重放到 main 之上 |
git rebase -i HEAD~3 | 交互式编辑最近 3 个提交 |
git rebase --abort | 取消正在进行的变基 |
git rebase 与 merge 常见问题
git rebase 和 git merge 有什么区别？
git merge 通过创建一个新的合并提交把两个分支连在一起，完整保留发生过的记录。git rebase 则移动你的提交，让它们在另一个分支之上重放，得到一条直线式的历史，但这些提交会被改写，获得新的哈希值。merge 保留历史；rebase 为了整洁而改写历史。什么时候用 merge，什么时候用 rebase？
整合一个已完成的分支（尤其是共享分支）时用 merge，它安全且不会破坏任何东西。在分享之前整理自己的本地提交，或者把功能分支更新到最新的
main 以保持历史整洁时，用 rebase。很多团队的做法是：本地 rebase，再 merge 到 main。变基的黄金法则是什么？
永远不要对别人已经基于它开展工作的提交执行变基，通常就是你已经推送到共享分支上的任何提交。因为 rebase 会改写提交，这样做会迫使其他人去处理分叉的历史。对本地尚未推送的提交可以放心变基；已经公开的提交请用 merge（或 revert）。
rebase 和 merge 哪个冲突更少？
两者都无法避免冲突，只是暴露冲突的方式不同。merge 在合并提交中一次性解决所有冲突。rebase 在重放每个提交时，可能会要求你逐个提交地解决冲突。总工作量差不多，rebase 只是把它分摊开了。
可以在线练习吗？
可以。打开终端在线编辑器，就能在浏览器里的真实 shell 中运行
git merge 和 git rebase，无需安装。Coddy 的免费互动 Git 课程也会一步步教你合并与变基。相关资源
更多 Git 命令
