Gitlab、Gitlab在进行Merge Pull Request都可以选择Squash将提交进行合并，但是他们在各自处理时却略有不同。

内部原理上，他们都需要使用git merge --squash 来实现。这个命令本质上是会在当前HEAD指向的Commit节点之后，将目标分支上的所有修改复制过来并生成新的提交（前提是没有冲突，若有冲突，需要合并后手动提交）。

通过git命令，手动做一些测试。

feature分支和mater分支有冲突，直接Merge squash时解决冲突

先通过Merge合同Master分支；Checkout Master分支，并Merge Squash feature分支

可以看到，两者都是生成一个新的和原分支无关的提交的。测试这两个的原因是，直接merge squash时解决冲突在Gitlab、Github中不一定可行，因为必须得在线解决冲突，我们实际开发的时候是需要通过merge/rebase先和master分支代码进行同步的。

GithubH2

Github文档是这么描述的About pull request merges - GitHub Docs

When you click the default Merge pull request option on a pull request on GitHub.com, all commits from the feature branch are added to the base branch in a merge commit. The pull request is merged using the --no-ff option.

Main分支上只产生一个新的Merge Squash提交

GitlabH2

By default, GitLab creates a merge commit when a branch is merged into main. A separate merge commit is always created, regardless of whether or not commits are squashed when merging. This strategy can result in both a squash commit and a merge commit being added to your main branch.

文档里提到，默认gitlab总会产生一个Squash Commit以及Merge Commit。Gitlab实际是执行类似这样的操作

bash
git checkout `git merge-base feature main`
git merge --squash <feature>
SOURCE_SHA=`git rev-parse HEAD`
git checkout <main>
git merge --no-ff $SOURCE_SHA

但是实际测试的发现，gitlab并不会在这个节点git merge-base feature main上进行merge；还是会在master分支的最新节点上merge，也就是图中绿色线的部分。

最终的Merge Commit是否产生，还是依赖于merge时是否使用Fast forward。 ] 上图是Merge之前进行rebase，然后合并时可以选择FF来避免Merge Commit的产生，实际不使用rebase，而用merge也能实现一样的效果。