重排提交顺序是什么
在 git rebase -i 的待办清单里上下移动整行，就能改变提交的应用顺序。它常用于把同主题的提交聚在一起、把「修复上一个提交」的改动挪到正确位置。风险在于提交之间可能存在依赖：后一个提交的代码可能建立在前面提交之上。
基本信息
| 作用 | 改变提交在历史中的先后顺序 |
|---|---|
| 操作方式 | 在编辑器里上下移动整行，保存退出后按新顺序重放 |
| 常见动机 | 把同一主题的提交聚拢，方便评审与回溯 |
| 主要风险 | 重排后中间状态可能编译不过或测试不通过 |
| 冲突处理 | 重放遇到冲突逐个解决，然后执行 git rebase --continue |
典型使用场景
- 提评审前整理同主题提交，让历史读起来是连贯的一步步
- 把「修正上一个提交」的改动挪到被修正的提交之后
- 把文档修改与代码修改分成两组，便于分类审阅
- 为后续压缩提交做准备，先把相关提交聚在一起
- 让待办清单顺序与实际开发顺序一致，方便他人理解
常用示例
常用示例
git rebase -i origin/main # 打开待办清单
# 在编辑器中直接上下移动整行即可改顺序，例如：
# pick a1b2c3 feat: 新增登录接口
# pick d4e5f6 fix: 修正上一个提交的拼写
git rebase --continue # 出现冲突并解决后继续重放
git rebase --abort # 顺序改错时中止，回到操作前状态
git log --oneline -8 # 核对重排后的实际顺序重排常见问题
| 情况 | 表现 | 处理 |
|---|---|---|
| 后续提交依赖前面改动 | 中间提交编译失败 | 把有依赖的提交保持在后面 |
| 重放产生冲突 | 变基暂停等待解决 | 逐块解决后继续，必要时中止 |
| 位置挪错 | 历史顺序不符合预期 | 用 reflog 找回原状态重做 |
重排属于重写历史：重放后每个提交的哈希都会变化，之后推送远端需要强推，并且要与正在使用该分支的同事打招呼。
不要在已经共享给多人的分支上随意重排：他人基于旧提交的改动会失去共同祖先，合并时出现成倍的重复冲突。