😶 Github Pull Request 三种合并方式

merge pull request（创建合并提交）【默认】

commit id 不变，会多生成一个merge pull request的提交。如果使用git merge命令可能出现重复的提交历史，因为upstream 分支上commit id是已经变化（内容是一模一样，但会被认为是不同的两次提交）。

squash and merge（压缩与合并）

一个pr中的所有commit都会被压缩为一个总的commit再合并。假设原pr中有5次提交，压缩并合并后只会有一个commit。
格式如下：

rebase and merge（变基与合并）

使用 github rebase and merge 会把pr中的每个提交的提交者都修改为 author + reviewer，且重新生成commit id，造成提交历史混乱。在这个pr合并后，如果开发者不基于最新的上游分支（upstream）分叉新创建分支，而是继续使用本地分支；如果要更新当前分支，那么这个开发者必须使用 git rebase 来变基到upstream分支上。

为什么不使用git merge？如果使用git merge命令就会出现重复的提交历史，因为 upstream 分支上是commit id是已经变化的提交（虽然提交的内容是一模一样，但还是会被人为是不同的两次提交）。
假如此开发者提交一次后，推送到远端并创建pr；该pr中原本应该只有一次提交，但是却多出来2次重复的提交。这就导致了历史的混乱。如下，红框中为重复的提交：

而使用git rebase，git 可以检测到重复的提交，即你本地的提交与远端github rebase后的提交是一回事（只是github rebase 更改了你的commit id），故在本地使用git rebase可以直接将本地分支更新为upstream上最新的（本地的commit id等信息被upstream 上的直接覆盖）。

pr中显示有数个提交，但是实际有影响的只有最新的那一个提交（重复的提交只会影响历史，并不影响代码内容，重复提交的更改已经合并过了）。但是将重复的提交历史合入仓库中，会影响代码仓库的历史追溯（可以使用squash and merge 来压缩这一次pr）。开发者打开pr查看历史会感到迷惑，所以应该要避免这种情况。

相关资料小结：

1. 审查者一定要认真审视pr所包含的内容及带来的影响。
2. 开发者最好不要长期使用一个分支。在更新本地分支时，merge or rebase 都会带来新的重复的提交（以前的提交都被认为是一个新的提交），继续用该分支新建pr，就有可能引入重复的提交。
3. 合并后就删除来源分支也有帮助