看起来这就是rebase的--preserve-merges所做的
实际上，Git 2.22，Q2 2019，实际上是deprecates--preserve-merge，Git 2.25，Q1 2020，stops advertising it in the " git rebase --help " output。
我在this answer中展示了最近的--rebase-merges选项（Git 2.18，Q2 2018）。

# Start interactive rebase with merge commits being treated as one
git rebase -i --rebase-merges <sha-of-merge-commit>^

# The interactive rebase to-do list will open in your editor.
# Move the merge commit to the desired position relative to other commits.
# Save and exit the editor to apply the reordering.

字符串
正如评论中提到的by j6t：
这仍然列出了来自分支分支的所有提交。
但是如果它们在todo列表中保持不变，历史将不会线性化。
的确，当你进行一个交互式的变基，并打算对合并提交重新排序时，Git需要知道原来合并的提交，这样它才能在新的历史中准确地重新创建合并。如果你不改变待办事项列表中的这些行，Git将按照原来的方式执行合并，而不会线性化历史。
如果你要删除或编辑对应于侧分支提交的行，你将有效地重写该分支的历史，这可能导致线性化的历史-这意味着合并将不再显示为合并，而是显示为一系列单独的提交。
为了确保合并提交被保留为合并，并且合并后的分支的历史没有被线性化，你应该保留分支提交的行，因为它们在rebase to-do列表中。这样，当rebase被执行时，Git将重新创建合并，并保持原始历史的完整性，包括分支分支的提交。

看起来这就是rebase的--preserve-merges所做的。