我们在开发一个功能时，提交记录往往真实地反映了我们的“心路历程”。但这种“流水账”式的提交，在团队协作中却是一个“灾难”。

一个典型的“坏”提交历史 vs. 一个“好”的提交历史：

图解： 左侧是5个琐碎的提交，而右侧理想情况下，我们希望将它们合并成一个清晰的、原子性的功能提交。

本文将手把手教你使用 Git 中最强大的历史编辑工具——交互式变基 (Interactive Rebase)，来将多个零散的提交合并成一个，让你的提交历史焕然一新。

1. 为什么需要修改（合并）提交历史？

在将你的功能分支推送到远程并与团队共享之前，整理提交历史是一个非常重要的专业习惯。

• 提升代码审查效率: 审查者可以专注于一个完整的提交，而不是在5个琐碎的提交中来回跳转。
• 保持主干历史清晰: 让项目的主干历史清晰易读，便于未来追溯。
• 方便问题定位与回滚: 如果未来发现 Bug，只需 revert 这一个提交即可。

黄金法则：
永远不要修改（rebase）一个已经推送到公共远程，并且团队其他成员可能已经拉取了的分支历史！ 修改历史只应在你的个人、未共享的本地分支上进行。

2. 核心武器：git rebase -i (交互式变基)

git rebase -i 会打开一个交互式的文本编辑器，里面列出了你指定范围内的所有提交，像一张“行动计划清单”。你可以在这个清单上，告诉 Git 接下来要对每个提交做什么。

如何启动？
最常用的命令格式是：git rebase -i <base>

• 修改最近的 N 次提交: git rebase -i HEAD~5
• 修改当前分支相对于另一个分支的所有提交: git rebase -i main

3. 实战演练：一步步合并你的“流水账”

rebase -i 的完整工作流程图：

graph TD
    A[开始: git rebase -i HEAD~N] --> B[Git 在编辑器中打开“行动计划”];
    B --> C{用户编辑计划};
    C -- 将 pick 修改为 squash/fixup 等 --> D[用户保存并关闭编辑器];
    D --> E{计划中是否有 squash/reword?};
    E -- 是 --> F[Git 再次打开编辑器, 让用户合并/修改提交信息];
    F --> G[用户编辑最终的提交信息后, 保存并关闭];
    E -- 否 --> H[Git 开始根据计划重写历史];
    G --> H;
    H --> I{重写过程中有冲突?};
    I -- 否 --> J[成功! 生成了新的提交历史];
    I -- 是 --> K[Git 暂停, 提示冲突];
    K --> L[用户解决冲突后, 执行 git rebase --continue];
    L --> H;
    J --> M[结束];

第一步：检查当前历史

git log --oneline 查看你的“流水账”。

第二步：启动交互式变基

git rebase -i HEAD~5

第三步：编辑“行动计划”

Git 打开编辑器，将默认的 pick 修改为 squash (或 s)。
修改前：

pick d5e6f7g feat: 添加登录表单
pick b4c5d6e fix: 修复上次提交的拼写错误
...

修改后：

pick d5e6f7g feat: 添加登录表单
squash b4c5d6e fix: 修复上次提交的拼写错误
squash f1e2d3c feat: 完成登录按钮
squash a2b3c4d wip
squash c3a4b5f fix: 解决样式错位

保存并关闭编辑器。

第四步：合并提交信息

由于使用了 squash，Git 会再次打开编辑器，让你编写合并后的新提交信息。
删除所有旧信息，编写一个全新的、有意义的 Commit Message：

feat: 完成用户登录功能

- 实现用户登录表单的 UI 布局
- 增加登录按钮的点击事件
- 修复相关 CSS 样式错位问题

再次保存并关闭编辑器。

第五步：检查最终结果

git log --oneline 查看，你会发现5个旧提交已合并成1个新提交。

4. squash vs. fixup：我该用哪个？

这两者都用于合并，但对 Commit Message 的处理方式不同。

一个清晰的对比：

假设我们有以下“行动计划”：
pick AAAAAAA feat: add user model
?????? BBBBBBB fix: correct typo in user model

---------------------------------------------------------------------

如果使用 squash:
    pick   AAAAAAA feat: add user model
    squash BBBBBBB fix: correct typo in user model
    
    结果 -> Git 会打开编辑器，内容包含 A 和 B 的两条 message,
            让你合并成一条新的 message。

---------------------------------------------------------------------

如果使用 fixup:
    pick  AAAAAAA feat: add user model
    fixup BBBBBBB fix: correct typo in user model
    
    结果 -> Git 不会打开编辑器，直接丢弃 B 的 message,
            最终提交只使用 A 的 message。

选择建议：

• squash (压缩): 当被合并的提交信息有价值，需要参考或整合时使用。
• fixup (修复): 当被合并的提交信息是无意义的“噪音”（如 “fix”, “wip”）时使用，这是更高效的选择。

5. 风险与“后悔药”

再次强调黄金法则：
不要 rebase 一个已经推送到公共远程、且被团队成员使用的分支！

如果你在本地 rebase 过程中搞砸了，怎么办？
Git 提供了终极后悔药 git reflog。它记录了你本地 HEAD 的所有移动历史。你可以找到 rebase 开始前的那个点的 Commit Hash，然后用 git reset --hard <hash> 来一键回到过去，重新开始。

总结

git rebase -i 是一个极其强大的“Git 历史美容工具”。通过熟练运用 pick, squash, fixup 等命令，我们可以将开发过程中的“流水账”式提交，精炼成一份清晰、专业、具有可读性的“作品集”。

这不仅是对代码审查者的尊重，更是专业精神的体现。记住，你的 Commit Message，是你留给未来自己和同事的、最重要的“代码注释”。一个干净的提交历史，是比任何文档都更宝贵的财富。