GitHub默认合并PR到master时保留原提交与合并提交是否正常？

核心结论 #

你观察到的现象是GitHub PR默认合并选项的标准正常行为，不存在操作失误或平台异常。

底层逻辑说明 #

GitHub默认选中的合并选项为「Create a merge commit」，底层强制使用带--no-ff（非快进）参数的Git三方合并逻辑，和本地手动执行Git默认合并的行为有明确区别：

• 本地Git执行合并时，如果源分支的提交直接接续在目标分支最新提交之后、双方没有分叉，会默认触发快进（fast-forward）合并：直接移动目标分支指针到源分支最新提交位置，既不会生成额外的合并提交，也不会改动源分支上的原有提交
• GitHub的默认合并强制禁用了快进逻辑，无论分支是否存在分叉，合并完成后一定会生成一条独立的合并提交
• 合并过程中，PR源分支上的所有原始提交会完整保留到目标分支的提交历史中，提交哈希、作者信息、提交说明、变更内容都和PR分支内的原始提交完全一致
• 系统自动生成的合并提交默认信息格式为Merge pull request #XXX <源分支名> into <目标分支名>，该提交包含两个父节点：分别是合并操作触发时目标分支的最新提交、PR源分支的最新提交

你提到的「仅包含1条提交的PR合并后，master分支出现2条新提交」的案例完全符合上述逻辑：1条是PR内的原始提交，1条是系统生成的合并提交。

认知偏差说明 #

你此前记忆里「默认合并只会生成一条汇总PR所有变更的单独提交」的表现，实际对应GitHub提供的squash and merge选项：该选项会把PR内的所有提交压缩为一个全新的提交追加到目标分支，不会保留PR内的原始提交记录，也不会额外生成合并提交。
很多从业多年的开发者没观察到这个默认特性非常正常：如果团队长期使用squash合并、本地合并默认开启快进、或者查看提交历史时习惯使用折叠合并节点的视图，都很容易忽略默认非快进合并会完整保留PR全量原始提交的特性。

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