title: rebase 还是 merge？我自己的小约定 date: 2026-04-08 tag: Git summary: 团队协作时 rebase 与 merge 都有用武之地，按场景选择比死守一种方式更重要。

刚开始用 Git 的时候，我对 git rebase 和 git merge 的区别理解得很模糊，往往是看着教程照搬命令。后来在自己的项目里反复踩坑，慢慢摸出了一套适合个人开发的小约定。

两者到底有什么不同

简单说：

• merge：保留分支的真实历史，会多出一个合并节点。
• rebase：把当前分支的提交"挪"到目标分支的最新一笔之后，历史看起来是一条直线。

举例，feature 分支基于 main 上的 A，又提交了 B、C；同时 main 上别人提交了 D。

merge:        A — D — M
                \   /
                 B — C

rebase:       A — D — B' — C'

我自己的小约定

1. 个人尚未推送的本地分支 —— 大胆 rebase。重写本地历史不会影响别人。
2. 已经推到远端、且只有自己用的分支 —— 谨慎 rebase，需要 --force-with-lease。
3. 多人共用的分支（main、develop） —— 永远不 rebase，永远 merge。
4. 要把 feature 合回 main 时 —— 我倾向 rebase 整理一下提交，再用 merge --no-ff 合入，既有线性历史，又能从合并点看出"这是一个完整的功能"。

常用命令

# 把当前分支的提交挪到 main 之上
git checkout feature
git rebase main

# 合并时强制保留合并节点
git merge --no-ff feature

# 已经 push 的分支被自己 rebase 后，要安全地强推
git push --force-with-lease

一个常见的坑

rebase 过程中如果有冲突，要 git add 解决后用 git rebase --continue，不是 git commit。中途想放弃就 git rebase --abort 退回原状。