rebase 的核心是保持提交历史的整洁。

1. 定义

git rebase，变基。

本质是把你分支上的一系列提交，在另一个基底上（通常是主分支的最新 commit）重放一遍。目标是让你的分支历史看起来像是直接从主分支最新点开发出来的。

• 变基前: A---B---C (feature 分支) / D---E---F---G (main 分支)
• 变基后: A'--B'--C' (feature 分支) / D---E---F---G (main 分支) A、B、C 的内容没变，但它们的 commit ID 变了，成了 A’、B’、C’。

2. 对比 Merge

特性	rebase	merge
历史线	线性、干净	非线性，保留分叉记录
提交记录	重写历史（ID变化）	新增一个合并提交
优点	历史清晰，易于追溯	真实记录所有开发轨迹
缺点	破坏了原始提交记录	合并提交过多，历史杂乱

选择哪个，是团队规范问题，不是技术优劣问题。

3. 使用原则

• 黄金法则：永远不要对公共分支（如 main, develop）执行 rebase。
  • 任何已经推送到远程，并且可能有他人拉取了的分支，都算公共分支。
  • 重写公共历史会给所有协作者带来混乱。
• 适用场景：
  1. 同步主干更新：在个人开发分支上，定期 rebase 主分支，获取最新代码，避免将来巨大的合并冲突。
  2. 整理提交历史：在提交 Pull Request (PR) 之前，使用交互式 rebase 清理自己的 commit 记录。

4. 基本操作

命令

# 切换到你的特性分支
git switch feature

# 拉取主干最新代码 (非必须，但推荐)
git fetch origin main

# 将 feature 分支变基到最新的 main 分支上
git rebase origin/main

冲突解决

1. rebase 过程因冲突暂停。
2. 手动解决文件中的冲突。
3. 执行 git add <解决冲突的文件>。
4. 执行 git rebase --continue 继续重放下一个提交。

如果过程复杂或出错，用 git rebase --abort 可以随时撤销，回到 rebase 开始前的状态。

5. 交互式 Rebase (-i)

这是 rebase 最强大的功能。用于在推送前整理本地提交。

命令

# 整理最近的 3 个提交
git rebase -i HEAD~3

执行后，会进入一个文本编辑器，列出你的提交：

pick 1a2b3c4 feat: add feature A
pick 5d6e7f8 fix: fix bug in A
pick 9g8h9i0 chore: typo

常用指令

• p, pick：保留该提交（默认）。
• r, reword：保留该提交，但修改提交信息。
• s, squash：将该提交合并到上一个提交中，并合并提交信息。
• f, fixup：同 squash，但丢弃该提交的提交信息。
• d, drop：删除该提交。

例如，将后两个提交合并到第一个：

pick 1a2b3c4 feat: add feature A
s 5d6e7f8 fix: fix bug in A
f 9g8h9i0 chore: typo

保存退出后，3 个提交会变成 1 个，历史记录非常干净。

6. 风险与补救

• 风险：rebase 会重写历史，如果操作不当，可能丢失提交。
• 补救措施：git reflog。
  • 该命令记录了你本地仓库所有 HEAD 的移动历史。
  • 如果 rebase 搞砸了，可以通过 reflog 找到 rebase 之前的 commit ID。
  • 使用 git reset --hard <commit_id> 即可恢复到指定状态。

reflog 是你的安全网。