🎯 什么时候用 Rebase?(实战指南)
✅ 场景 1:同步主分支的最新代码(最常用)
情况:你在开发 feature,但 main 分支已经有新提交了,你想把新代码拉过来。
bash
# 你在 feature 分支工作了 3 天
git checkout feature/my-work
# 这时 main 分支有了新提交(别人合并了代码)
# 你想同步这些新代码
git fetch origin
git rebase origin/main # ✅ 用 rebase!
# 结果:你的提交现在基于最新的 main,避免了冲突
为什么用 rebase?
避免无意义的合并提交
让你的 feature 分支保持在最新代码之上
提交历史更清晰
✅ 场景 2:拉取远程更新(日常操作)
情况:你要拉取远程的最新代码
bash
# ❌ 不推荐(会产生多余的合并提交)
git pull
# ✅ 推荐(历史干净)
git pull --rebase
对比效果:
使用 git pull(merge):
bash
你的提交: A → B → C
远程提交: A → B → D
拉取后:
A → B → C ────→ M(合并提交)
↘ ↗
D
历史:有个多余的合并提交 M
使用 git pull --rebase:
bash
你的提交: A → B → C
远程提交: A → B → D
拉取后:
A → B → D → C'
历史:一条直线,干净!
✅ 场景 3:整理本地提交(让历史更专业)
情况:你在本地做了很多小提交,想整理一下再推送
bash
# 你的提交历史很乱:
git log --oneline
abc123 fix typo
def456 fix typo again
ghi789 add feature
jkl012 debug
mno345 final version
# 使用交互式 rebase 整理
git rebase -i HEAD~5 # 整理最近 5 个提交
# 可以:
# - 合并多个提交(squash)
# - 修改提交信息(reword)
# - 删除提交(drop)
# - 重新排序
❌ 场景 4:永远不要用 Rebase 的情况
🚫 情况 1:已经推送到远程的公共分支
bash
# main 分支已经推送,别人都在用
git checkout main
git rebase feature # ❌ 千万不要!
# 会导致:
# - 所有人的仓库都乱套
# - 同事需要重新克隆仓库
# - 团队会恨你 😅
🚫 情况 2:多人协作的分支
bash
# 你和同事都在 feature 分支工作
git checkout feature
git push origin feature # 同事看到了你的提交
# 然后你 rebase...
git rebase main # ❌ 不要!
git push -f origin feature # ❌❌ 更不要!
# 后果:同事的仓库会出问题
📋 快速决策表
问自己这些问题: 问题 答案 用什么
条件 | 选项 | 建议操作 | 说明 |
---|---|---|---|
这个分支只有我在用吗? | 是 | ✅ Rebase | 未共享的分支可安全重写历史,避免干扰他人。 |
否 | ❌ Merge | 多人协作分支需保留原始提交记录,避免历史冲突。 | |
代码已经推送到远程了吗? | 是 | ❌ Merge | 已推送的代码若强制 Rebase 会破坏他人历史,需谨慎。 |
否 | ✅ Rebase | 本地未推送的提交可自由整理,保持线性历史。 | |
是 main/master 分支吗? | 是 | ❌❌ 绝不 Rebase | 主分支必须保持绝对稳定,禁止重写历史。 |
想保留完整的开发历史吗? | 是 | ❌ Merge | Merge 保留分支合并轨迹,适合需要追溯完整上下文的场景。 |
想要干净的线性历史吗? | 是 | ✅ Rebase | Rebase 将提交"移植"到主分支最新节点,形成无分叉的直线历史。 |
🎬 真实工作流程示例
你的典型一天:
bash
# ========== 早上开始工作 ==========
# 1. 确保 main 是最新的
git checkout main
git pull --rebase # ✅ 用 rebase 保持干净
# 2. 创建 feature 分支
git checkout -b feature/add-login
# 3. 写代码,提交
git add .
git commit -m "feat: add login form"
git commit -m "feat: add validation"
# ========== 中午同事合并了代码 ==========
# 4. 同步 main 的新代码到你的 feature 分支
git fetch origin
git rebase origin/main # ✅ 用 rebase!
# 5. 解决冲突(如果有)
# 编辑文件 → git add . → git rebase --continue
# ========== 下午完成功能 ==========
# 6. 推送你的分支
git push origin feature/add-login
# 7. 在 GitHub 创建 Pull Request
# 8. 代码审查通过后,合并到 main(在 GitHub 上点击)
# GitHub 会用 Merge,不是 Rebase!✅
# ========== 清理 ==========
# 9. 删除已合并的 feature 分支
git checkout main
git pull
git branch -d feature/add-login
🔥 常用命令速查
bash
# ========== 日常 Rebase ==========
git pull --rebase # 拉取远程,用 rebase
git rebase main # 将当前分支 rebase 到 main
git rebase origin/main # rebase 到远程 main
# ========== 交互式 Rebase(整理历史)==========
git rebase -i HEAD~3 # 整理最近 3 个提交
git rebase -i main # 整理从 main 分叉后的所有提交
# ========== Rebase 出错时 ==========
git rebase --abort # 放弃 rebase,回到之前的状态
git rebase --continue # 解决冲突后继续
git rebase --skip # 跳过当前提交
# ========== 查看历史 ==========
git log --oneline --graph # 图形化查看提交历史
💡 我的建议(新手友好)
📌 Stage 1:完全不用 Rebase(学习 Git 的第 1 个月)
bash
git pull # 只用 merge
git merge # 合并用 merge
优点:安全,不会搞乱历史
📌 Stage 2:只在安全场景用 Rebase(2-6 个月)
bash
git pull --rebase # ✅ 只在拉取时用
git rebase origin/main # ✅ 只在本地未推送的分支用
优点:历史更干净,但不会出大问题
📌 Stage 3:高级用法(6 个月以后)
bash
git rebase -i # 交互式整理提交
git rebase --onto # 高级分支操作
⚡ Rebase 的核心规则:
如果只有你在用这个分支,用 Rebase;
如果别人也在用,用 Merge。
🎓 作业(可选)
你现在可以试试:
bash
# 1. 创建一个测试分支
git checkout -b test/rebase-practice
# 2. 做一些修改并提交
echo "test" > test.txt
git add test.txt
git commit -m "test commit"
# 3. 切回 main 也做修改
git checkout main
echo "main" > main.txt
git add main.txt
git commit -m "main commit"
# 4. 回到测试分支,rebase 到 main
git checkout test/rebase-practice
git rebase main
# 5. 查看历史
git log --oneline --graph
# 6. 清理
git checkout main
git branch -D test/rebase-practice