merge 和 rebase 都能把两条历史合到一起，但它们表达的协作语义不一样。
简单说：
merge 保留分支合并历史rebase 把当前分支的提交移动到新的基底上公共分支上的历史已经被别人看到或基于开发时，优先使用 merge 或 revert，避免随意重写历史。
如果一个 feature 分支代表一组完整工作，merge commit 可以保留这次合入的上下文。
一些团队希望从历史上看到“什么时候把哪条分支合进来”，这时 merge 更合适。
本地还没 push 时，可以用交互式 rebase 整理 commit：
git rebase -i HEAD~3
常见操作：
git fetch origin
git rebase origin/main
这样可以让你的分支历史排在最新主分支之后。
部分团队喜欢线性历史，会要求 feature 分支合入前 rebase 到主分支最新位置。
不要随意 rebase 已经被别人基于开发的公共分支。
GitHub 文档也提醒，rebase 会改写提交历史，已经 push 到仓库的 commit 再 rebase，会给其他协作者带来麻烦。
| 场景 | 推荐 |
|---|---|
| 本地未 push 的整理 | rebase |
| feature 分支同步主分支 | rebase 或 merge，按团队约定 |
| 主分支合并 PR | merge、squash、rebase merge，按仓库策略 |
| 公共历史出错 | revert |
| 已经有人基于你的分支开发 | 避免 rebase |
git merge feature/login
git rebase origin/main
git rebase -i HEAD~3
git rebase --abort
git rebase --continue