GitHub创建合并提交时为何会将特性分支所有提交加入main分支？

先纠正你的理解偏差 #

你之前对git merge的认知只覆盖了**快进合并（fast-forward）**的场景，但Git还有另一种核心合并模式：非快进合并（no-fast-forward），也就是GitHub默认合并PR时使用的git merge --no-ff。

• 快进合并：如果main分支在你创建特性分支后没有新增任何提交，git merge会直接将main的指针移动到特性分支的最后一个提交，不会生成新的合并提交，特性分支的所有提交会直接出现在main的历史中。
• 非快进合并：当main有新提交，或者用--no-ff强制触发时，Git会生成一个新的合并提交（就是你看到的那个额外提交），这个提交的父节点是main的最后一次提交和特性分支的最后一次提交。但特性分支的所有提交依然会保留在main的提交历史里——这不是GitHub的特殊操作，是标准的非快进合并结果。

你误以为git merge只会添加合并提交，本质是把两种合并模式的效果搞混了。

为什么GitHub的Code视图看起来“混乱”？ #

GitHub的Code视图默认展示的是线性化的提交历史，它会把特性分支的提交按时间顺序插入到main的历史流中，看起来就像这些提交是直接在main上完成的。但真实的分支拓扑关系并没有改变，你可以通过两种方式查看真相：

• 在本地执行git log --graph命令，能清晰看到合并提交和分支的层级结构。
• 你提到的Insights分支图形视图，也能准确展示分支合并的实际情况。

目前GitHub没有提供关闭Code视图线性化历史的选项，只能通过上述两种方式查看真实的提交结构。

如何获得你预期的“仅添加合并提交”效果？ #

如果你希望main分支的历史中只有合并提交，特性分支的提交不直接暴露，那你需要的是压缩合并（Squash and merge）。针对你担心的复用分支问题，解决方法很明确：压缩合并完成后，对原特性分支执行git rebase main，将分支的基点移到main的最新提交，后续再在该分支上工作时，就不会重复出现已压缩的提交了。

要是你坚持使用普通合并，那特性分支的提交出现在main历史里是正常的——这就是非快进合并的标准行为，GitHub只是用线性化的方式展示了这些提交而已。

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