git log --topo-order合并提交父节点输出顺序规则及场景疑问

--topo-order 是 Git 提交历史的拓扑排序模式，运行逻辑分为两层：

• 全局硬约束：所有提交必须在它的所有祖先提交之前输出，绝对不会出现先展示祖先、后展示后代的倒序情况，这是拓扑序的核心要求。
• 同层节点遍历优先级：对于不存在互相依赖关系的同层提交（最典型的就是合并提交的多个父节点），Git 按照父节点在提交对象内部的存储顺序从后向前分配优先级——越靠后存储的父节点，优先级越高，越先被遍历；越靠前存储的父节点，优先级越低，越晚被遍历。

补充说明：Git 合并提交的父节点存储有固定规则：执行git merge生成合并提交时，第一父永远是命令执行时当前所在分支的头部提交，后续父节点按照merge命令传入的分支参数顺序依次存储。比如执行git merge feature时，生成的合并提交第一父为操作前当前分支的头，第二父为feature分支的头。

结合上述规则，标准PR合并场景天然会呈现“先输出功能分支父提交”的结果：

• 无论本地手动执行合并，还是代码平台生成的标准PR合并提交，最终生成的合并提交m的父节点存储顺序固定为：第一父是合并发生时master分支的头部提交，第二父是被合入的功能分支的头部提交。
• 按照优先级规则，第二父（功能分支头）的遍历优先级高于第一父（master旧头），因此Git从m开始做拓扑遍历时，会优先沿着第二父对应的功能分支提交链深入遍历，走完功能分支的所有提交后，才会回头遍历第一父对应的master提交链。
• 当执行git log -n 2 --topo-order --pretty=format:"%H"从m开始遍历时，第一个输出的是合并提交m本身，第二个输出的自然就是优先级更高的第二父——也就是功能分支的头提交，而非master侧的旧提交。

关于官方文档未明确保证该行为的原因：Git 仅将“子提交先于所有祖先提交输出”作为--topo-order的稳定承诺，而同层无依赖关系节点的遍历顺序属于内部实现细节，未被纳入永久稳定的API范围。理论上未来Git版本可以调整同层节点的优先级规则，只要不破坏核心拓扑约束，就不违反文档承诺。

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