含main分支合并记录的feature分支多提交压缩操作疑问

核心逻辑差异解析 #

1. git rebase -i HEAD~7的行为

你指定了从当前HEAD往前数7个提交作为变基范围，但Git变基默认会自动展开合并提交（相当于隐含--no-merges参数）。之前两次Merge main into feature的操作，本质是把main分支的几个提交（即你看到的New_commit_from_main_1/2/3）合并到feature里。变基时Git会拆掉这些合并节点，把main的提交直接线性插入到feature的提交历史中，原本的2个合并提交被替换成3个来自main的实际提交，最终就得到了包含A/B/C/D/E加上3个main提交的列表。

2. git rebase -i main的行为

这个指令的目标是把feature分支中所有不属于main分支的提交，以main为基底重新应用。你之前合并main的操作只是同步main已有的提交，这些提交本身已经存在于main分支，所以变基时Git会自动跳过这些合并进来的内容，只处理feature自己开发的A/B/C/D/E这5个提交，因此列表里只有这5项。

如何得到你预期的7行合并提交列表？ #

如果想在变基时保留合并提交节点，需要加上--preserve-merges（缩写-p）参数，执行：

git rebase -i -p HEAD~7

这样Git会保留原有的合并提交结构，你就能看到包含两次Merge main into feature的7行提交列表了。

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