git实战（9）git rebase 终极详解，看这一篇就够了！

一、Rebase 的本质

变基（Rebase） 的核心是 改变提交的基准点。

• 将当前分支的提交“嫁接”到目标分支的最新提交之上
• 效果：使提交历史呈线性结构（无合并提交）
• 类比：把一段提交记录“剪下来”，接到另一分支的末端

---

二、基础命令

1. 单分支变基

git checkout feature
git rebase main    # 将 feature 分支变基到 main 分支

执行后：

• feature 分支的基准点从 旧commit 变为 main 的最新提交
• feature 的提交历史重演在 main 之后

2. 交互式变基（-i）

git rebase -i HEAD~3  # 修改最近3次提交

进入交互界面，可执行：

• squash：合并提交
• edit：暂停修改提交内容
• reword：修改提交信息
• drop：删除提交

---

三、完整工作流程（含冲突解决）

# 1. 开始变基
git rebase main

# 2. 若发生冲突：
#   - 手动解决冲突文件
#   - 标记已解决：
        git add <file>
#   - 继续变基：
        git rebase --continue

# 3. 跳过当前提交（谨慎！）：
        git rebase --skip

# 4. 终止变基（回退到开始前状态）：
        git rebase --abort

---

四、核心应用场景

1. 整理本地提交历史

git rebase -i HEAD~5  # 合并/修改最近5次提交

用途：合并琐碎提交（如“修复拼写错误”）、重写提交信息。

2. 同步上游分支更新

git pull --rebase  # 等价于 git fetch + git rebase origin/main

优势：避免多余的合并提交（Merge branch 'main' into feature）。

3. 跨分支移植提交

git rebase --onto target-branch source-base-branch feature

场景：将 feature 分支中不包含 source-base-branch 的提交，移植到 target-branch。

---

五、危险操作与救赎

1. 强制推送改写远程历史

git push --force-with-lease  # 安全强制推送（检查远程是否被他人更新）

警告：仅限私有分支！公共分支需团队协商。

2. 找回误删提交

git reflog                  # 查找变基前的提交哈希
git reset --hard <old-hash> # 恢复历史

---

六、Rebase vs Merge 决策树

场景	推荐操作	原因
个人本地分支整理提交	rebase -i	清理历史，便于代码审查
更新功能分支代码	pull --rebase	避免污染历史记录
公共分支（如 main）合并	merge --no-ff	保留合并痕迹，便于追踪
已推送的共享分支	❌ 禁止 rebase	避免协作成员历史混乱

---

七、黄金法则

1. 私有分支：可随意 rebase（尚未推送到远程）
2. 公共分支：禁止 rebase（已与他人共享的分支）
3. 推送前：用 git log --graph 确认历史是否符合预期

---

八、高级技巧

1. 自动解决重复冲突

git config --global rerere.enabled true  # 开启“重用记录解决方案”

• Git 会记住冲突解决方式，下次相同冲突自动处理。

2. 变基时保留空提交

git rebase --keep-empty  # 保留无实际修改的提交（如文档更新）

3. 精确选择提交范围

git rebase -i --root     # 从第一个提交开始修改（重写整个历史）

---

九、可视化理解

          A---B---C  feature
         /
    D---E---F---G  main

# 执行 git rebase main feature 后：

                  A'--B'--C' feature
                 /
    D---E---F---G  main

注意：原始提交 A/B/C 被新提交 A’/B’/C’ 替代（内容相同，但父提交改变）

---

十、总结：Rebase 的利与弊

优点	缺点
提交历史线性整洁，易于阅读	改写历史可能破坏协作
避免无意义的合并提交污染历史	解决冲突可能重复多次
交互式操作可精细控制提交内容	丢失原始提交上下文（需 reflog）

最终建议：

• 个人分支：大胆使用 rebase 保持历史清爽
• 团队协作：优先用 merge，如需 rebase 务必全员同步操作
• 推送前：永远检查历史（git log --oneline --graph）