变基中的空提交是什么
变基会把分支提交逐个重放到新基点：内容已经被上游包含的提交重放后会变成空变更。用 --empty=drop|keep|stop 控制这类提交的处理；已被应用过的提交会先以 skipped previously applied commit 的提示被跳过。分清这两种来源，才能解释变基输出与结果差异。
基本信息
| 两种来源 | 已被上游包含（直接跳过并提示）、重放后变为空（由 --empty 控制） |
|---|---|
| 显式控制 | git rebase --empty=drop|keep|stop <上游> |
| 旧参数 | --keep-empty 等价于保留空提交 |
| 默认行为 | 非交互默认丢弃；交互模式遇到变空会停下待处理 |
| 相关提示 | skipped previously applied 与 --reapply-cherry-picks |
| 预判手段 | git cherry 按补丁对比上游是否已包含某提交 |
典型使用场景
- 分支落后很久再同步：大量提交已被上游包含，批量跳过是预期行为
- 清理重复提交：确认空提交无价值后让 drop 保持历史干净
- 交互变基中途变空：根据提示判断是继续、跳过还是保留
- 谨慎审查：用 --empty=stop 逐条确认再继续
- 变基前预判：用 git cherry 查看哪些提交已被上游包含
常用示例
常用示例
git rebase --empty=drop origin/main # 空提交直接丢弃
（非交互模式的默认即如此）
git rebase --empty=keep origin/main # 保留空提交，旧写法 --keep-empty
git rebase --empty=stop origin/main # 遇空提交停下，人工判断
git rebase -i origin/main # 交互模式默认在变空处停下遇空提交怎么办
| 情况 | 判断依据 | 动作 |
|---|---|---|
| 提交改动已在上游 | 提示 patch contents already upstream | 让它丢弃，无需处理 |
| 重放后变空但本应有改动 | 解决冲突时内容可能被吃掉 | 停下检查，不要急着跳过 |
| 确认无价值的空提交 | 历史清理场景 | --empty=drop 保持干净 |
| 想保留提交结构 | 发布演练或审计要求 | --empty=keep |
交互变基在空提交处停下时，提示可用 git commit --allow-empty 保留或 git rebase --skip 跳过，按场景二选一，处理完继续用 git rebase --continue 推进剩余提交。
大量空提交通常说明分支与主干有重叠：先确认这次变基是否必要，避免把同步问题包装成操作问题，可先看分支与上游的提交交集再决定。