Git Fixup 与 Pick：优雅整理提交历史

每个开发者都经历过这样的场景：在 Code Review 前夕，你的提交历史看起来像这样：

a1b2c3d feat: 用户登录页面完成
9f8e7d6 fix: 修复登录按钮样式
3c4d5e6 feat: 添加登录表单验证
7b8a9c0 fix typo
1a2b3c4 feat: 搭建项目基础结构

那几条 fix typo、fix: 修复... 的提交让历史记录显得凌乱，不仅阅读体验差，还会在 git blame 时干扰追溯。本文介绍如何用 git rebase -i 的 pick 和 fixup 指令一次性解决这个问题。

什么是交互式 Rebase？

git rebase -i（interactive rebase，交互式变基）允许你在将一系列提交应用到目标分支之前，对它们进行重新排序、合并、编辑或删除。

# 对最近 4 个提交进行交互式编辑
git rebase -i HEAD~4

执行后，Git 会打开一个文本编辑器，列出即将操作的提交列表，每行以一个指令关键字开头。

核心指令：pick 与 fixup

pick — 保留提交

pick（简写 p）是默认指令，表示原样保留这个提交，不做任何更改。

pick a1b2c3d feat: 用户登录页面完成
pick 3c4d5e6 feat: 添加登录表单验证

fixup — 静默合并

fixup（简写 f）表示将此提交的内容合并到上一个 pick 提交中，并完全丢弃本提交的提交信息。

pick a1b2c3d feat: 用户登录页面完成
fixup 9f8e7d6 fix: 修复登录按钮样式   ← 合并入上面的 pick，信息丢弃

squash — 交互式合并（对比）

squash（简写 s）与 fixup 类似，但会保留提交信息并打开编辑器让你手动合并两者的描述。

最佳实践：对于 "fix typo"、"oops" 这类没有语义价值的补丁提交，用 fixup；对于两个提交都有意义但想合为一条的，用 squash。

整理前的混乱历史

下图展示了一个典型的"凌乱"提交历史，红色/橙色节点是没有独立语义的补丁提交：

实战：手动编辑 rebase 列表

第一步：启动交互式 rebase，指定需要整理的提交范围

git rebase -i HEAD~4

第二步：编辑器打开后，将 fix 类提交的 pick 改为 fixup，并移动到对应的功能提交下方：

修改完成后保存退出（Vim：:wq，VSCode：直接关闭标签页）。

第三步：Git 自动完成变基。整理后的历史：

$ git log --oneline
e5f6a7b feat: 用户登录页面完成     ← 已悄悄包含 fix 补丁
8c9d0e1 feat: 添加登录表单验证     ← 已悄悄包含 fix typo
1a2b3c4 feat: 搭建项目基础结构

整理后的干净历史

噪音提交消失，每个节点都具备完整的语义含义：

进阶：--fixup + --autosquash 自动化工作流

手动改 rebase 列表容易出错，Git 提供了更自动化的方案：

第一步：用 --fixup 标记补丁提交

当你发现某个旧提交漏提了文件时，不要直接 git commit -m "fix"，而是：

# 先找到要修复的提交 hash
git log --oneline
# 假设要修复 3c4d5e6 这个提交
git add <修改的文件>
git commit --fixup 3c4d5e6

Git 会自动创建一个提交信息为 fixup! feat: 添加登录表单验证 的提交（加上 fixup! 前缀）。

a1b2c3d feat: 用户登录页面完成
f2e3d4c fixup! feat: 添加登录表单验证   ← 自动命名
3c4d5e6 feat: 添加登录表单验证
1a2b3c4 feat: 搭建项目基础结构

第二步：--autosquash 自动排序并整理

git rebase -i --autosquash HEAD~4

Git 会自动将所有 fixup! 前缀的提交移动到对应提交的下方，并将指令改为 fixup，你只需确认后保存即可。

# 如果你总是使用这个工作流，可以设为默认
git config --global rebase.autoSquash true

常见应用场景

场景一：代码审查前清理分支

# 功能开发期间随手提交
git commit -m "feat: 实现搜索功能"
# ... 开发过程中发现小问题 ...
git add fix.ts
git commit --fixup HEAD   # 修复最新提交

# 推送前一键清理
git rebase -i --autosquash origin/main

场景二：修复几个提交之前的漏提

# 查看历史，找到需要补充的提交
git log --oneline -10

# 标记 fixup 目标
git add forgotten-file.ts
git commit --fixup abc1234

# 清理
git rebase -i --autosquash HEAD~5

⚠️ 重要注意事项

不要对已推送到公共分支的提交进行 rebase。

git rebase 会重写提交历史（生成新的 commit hash），如果其他人已经基于这些提交工作，强制推送会造成冲突和困惑。

# 仅在个人功能分支上使用
git push --force-with-lease origin feature/my-branch  # 如果必须强推，至少用这个更安全的方式

安全的使用原则：

• ✅ 在推送之前，在本地功能分支上整理
• ✅ 在个人 fork 的分支上操作
• ❌ 不要 rebase main、master、develop 等共享分支
• ❌ 不要 rebase 已经有他人 PR 的分支

小结

掌握 fixup 和 pick，你的提交历史将从"流水账"升级为"精炼的功能日志"，让代码审查和历史追溯都更加愉快。