无参数执行git rebase为何会修改提交ID与提交顺序？

核心前提：无参数rebase的默认基准不是本地main分支 #

无参数执行git rebase时，Git不会自动选择本地main分支作为变基目标，而是读取当前分支配置的上游追踪分支作为变基基准：你操作时切换到feature分支的提示为Your branch is up to date with 'origin/feature'，说明feature分支的默认上游是远程的origin/feature，这是第二次rebase出现提交顺序、ID变更的核心根源。

第一次rebase后的实际提交状态 #

执行git rebase main完成后，本地feature分支的提交是基于本地main的M3提交重放生成的全新提交，和远程origin/feature的提交已经产生分叉，结构如下：

origin/feature (远程feature分支): M1 -- M2 -- F1 -- F2
本地feature (第一次rebase后): M1 -- M2 -- M3 -- F1' -- F2' -- F3

注意：F1'、F2'是rebase生成的新提交，虽然代码改动内容和原来的F1、F2完全一致，但提交ID完全不同。

第二次无参数rebase的完整执行流程 #

Git会按固定规则完成变基操作：

• 找到本地feature分支和上游追踪分支origin/feature的最近公共祖先，即提交M2。
• 提取本地feature上从M2之后的所有独有提交，按提交时间顺序为M3、F1'、F2'、F3。
• 将这些提交按原有顺序逐个尝试重放到上游分支的最新提交（即origin/feature的F2提交）之上。
• 重放过程中，Git会计算每个提交的patch-id（即剔除提交信息、时间等元数据，仅基于代码改动内容生成的唯一标识），如果发现某个patch-id已经存在于目标基准分支上，就会跳过该提交：F1'、F2'的代码改动和origin/feature上已有的F1、F2完全一致，因此触发skipped previously applied commit的警告，两个提交被直接跳过。
• 最终仅剩下M3、F3两个提交被重放，生成新的提交副本M3'、F3'拼接在F2之后，最终提交结构和你看到的日志完全匹配：

  M1 -- M2 -- F1 -- F2(origin/feature) -- M3' -- F3'(HEAD -> feature)
  

这就是提交顺序变化、提交ID全部更新的直接原因：第二次rebase实际是把本地main上的M3提交，变基到了远程旧feature分支的F2提交后面，而非将feature分支的提交放在M3之后。

无需--force即可推送的原因 #

第二次rebase完成后，本地feature的最新提交是直接继承自远程origin/feature的最新提交F2的，推送时属于快进（fast-forward）更新，没有改写远程分支上已经存在的提交历史，因此不需要加强制推送参数。

操作提示：如果需要基于本地main分支同步代码，永远显式指定目标分支执行git rebase main，不要依赖无参数rebase的默认逻辑，避免因为上游分支配置不符合预期导致提交顺序混乱。

内容的提问来源于stack exchange，提问作者Antonio