Git Rebase实战：重写提交历史的完整指南-开发者社区

1. 为什么我们需要重写提交历史？

作为一个每天与Git打交道的开发者，我经常遇到这样的场景：在本地开发分支上提交了十几个小改动，准备合并到主分支时，发现提交记录杂乱无章，包含大量"临时保存"、"修复bug"这类无意义的提交信息。更糟的是，可能还混入了敏感信息（如密码）或大体积文件。这时候，git rebase就是你的时间机器。

与merge不同，rebase不是简单地创建一个新的合并提交，而是将你的提交"重新播放"在目标分支的最新提交之上。想象你正在写一部小说，rebase就像是把草稿章节重新整理、润色后再交给编辑，而不是直接把原始草稿和修改意见一起堆过去。

重要提示：永远不要rebase已经推送到远程仓库且可能被他人基于其开发的提交！这会导致协作灾难。rebase只适用于本地未推送的提交。

2. 基础rebase操作实战

2.1 交互式rebase入门

假设我们有以下提交历史（通过git log --oneline查看）：

a1b2c3d (HEAD -> feature) 临时保存 e4f5g6h 修复样式问题 i7j8k9l 添加用户登录功能 m1n2o3p (origin/main) 主分支最新提交

要整理最后三个提交：

git rebase -i m1n2o3p

这时会打开编辑器显示：

pick i7j8k9l 添加用户登录功能 pick e4f5g6h 修复样式问题 pick a1b2c3d 临时保存

我们可以：

调整行顺序来改变提交顺序
将"pick"改为"squash"合并提交
将"pick"改为"edit"暂停rebase进行更复杂修改
删除行来完全移除提交

2.2 典型工作流示例

场景1：合并多个小提交

pick i7j8k9l 添加用户登录功能 squash e4f5g6h 修复样式问题 squash a1b2c3d 临时保存

保存后会进入提交信息编辑界面，可以编写一个更专业的提交信息，例如：

实现用户认证系统 - 添加基于JWT的登录接口 - 完善响应式布局 - 修复移动端样式错位问题

场景2：拆分过大提交将某个pick改为edit，rebase会在该提交处暂停。然后：

git reset HEAD~1 # 取消提交但保留更改 git add -p # 交互式选择要暂存的内容 git commit # 创建第一个新提交 git commit # 创建第二个新提交 git rebase --continue

3. 高级rebase技巧

3.1 修改历史提交中的内容

有时我们需要修改某个旧提交中的文件内容（比如删除误提交的密码）。在rebase -i中将对应提交标记为edit，暂停后：

git checkout HEAD~1 -- config.yml # 检出旧版本文件 vim config.yml # 编辑文件 git add config.yml git commit --amend # 修改提交 git rebase --continue

3.2 处理rebase冲突

rebase过程中遇到冲突时：

Git会暂停并标记冲突文件
手动解决冲突后git add这些文件
不需要commit，直接git rebase --continue
如果想放弃，使用git rebase --abort

专业建议：在开始rebase前先执行git config --global rerere.enabled true启用"rerere"（重用记录的冲突解决方案）功能，Git会记住你如何解决特定冲突，下次自动应用。

3.3 使用--onto进行复杂重组

假设你有这样的分支结构：

A---B---C---D main \ E---F---G feature \ H---I sub-feature

想把sub-feature分支从基于F改为基于D：

git rebase --onto main F sub-feature

结果：

A---B---C---D main | \ | H'---I' sub-feature \ E---F---G feature

4. 危险操作与救赎指南

4.1 恢复误操作的rebase

即使搞砸了rebase，Git也提供了多种后悔药：

reflog大法：

git reflog # 找到rebase前的commit hash git reset --hard [hash]

ORIG_HEAD： Git在进行危险操作前会自动保存引用到ORIG_HEAD：

git reset --hard ORIG_HEAD

临时引用： rebase过程中每个原始提交都会被保存为：

refs/original/refs/heads/[branch-name]

4.2 强制推送的注意事项

如果必须推送rebase后的分支（比如个人特性分支）：

git push --force-with-lease

比--force更安全，会在远程分支已被他人修改时拒绝强制推送。

5. 企业级最佳实践

5.1 代码审查中的rebase策略

在发起Pull Request前：
- rebase到目标分支最新提交
- 合并琐碎提交
- 编写清晰的提交信息
审查期间：
- 不要rebase已进入审查的分支
- 新改动通过git commit --fixup=[target-commit]添加
- 审查通过后使用git rebase -i --autosquash自动整理

5.2 提交信息规范

好的提交信息结构：

类型(范围): 简明主题 详细说明，解释为什么需要这个改动， 而不是这个改动做了什么（代码本身已展示）。 关联的问题追踪ID：JIRA-123

常用类型：

feat：新功能
fix：错误修复
docs：文档变更
style：代码格式调整
refactor：重构代码
perf：性能优化
test：测试相关
chore：构建过程或辅助工具变更

5.3 自动化工具集成

使用pre-commit钩子检查提交信息格式：

# .git/hooks/pre-commit if ! grep -qE '^(feat|fix|docs|style|refactor|perf|test|chore)\(.*\): .+' "$1"; then echo "Invalid commit message format!" >&2 exit 1 fi

使用GitLens等IDE插件可视化rebase过程
配置alias简化常用操作：

[alias] ri = rebase -i rc = rebase --continue rs = rebase --skip ra = rebase --abort

6. 我踩过的那些坑

时间戳混乱： rebase会重写提交时间，导致git blame时显示不准确。解决方法：

git rebase -i --committer-date-is-author-date

二进制文件冲突：对于经常冲突的二进制文件（如.xlsx），在.gitattributes中添加：

*.xlsx merge=binary

长运行rebase中断：如果rebase过程被意外中断（如电脑关机），可以：

git rebase --edit-todo # 修改待处理列表 git rebase --continue

幽灵提交：有时git log会显示已经rebase掉的提交。彻底清理：

git gc --prune=now

SSH连接超时：长时间rebase可能导致SSH连接断开。解决方法：

git config --global core.sshCommand "ssh -o ServerAliveInterval=60"

Git Rebase实战：重写提交历史的完整指南