「这是我参与2022首次更文挑战的第3天，活动详情查看：2022首次更文挑战」
提交github的PR时会显示所有commit的问题解决方案
起因
最近在空闲的时候给开源仓库提交代码，我发现会出现 之前提交并合并到 upstream 里的 commit仍然存在的现象。
具体现象如下图：
第一次PR
第二次PR
第三次PR
...
这样虽然对提交效果没有任何影响，但是却很影响我们在提交时的心情和检查提交记录的状态。所以我决定一探究竟，看看如何解决这个问题。
找原因
于是我在网上查了查看看有没有人遇到同样的问题，发现这个问题困扰的人还不少。当然也有不少好哥哥写了很多关于问题的解决方案，但是反反复复一直没有找到好的解决办法。
怎么办呢？
好吧，自己把提交的所有过程都模拟复现一遍，然后分析结果，看看能不能找到一个比较好的解决方案。
说干就干，我记得自己刚申请 github的时候，第一个库就是用来学习如何使用 git 进行提交的。嗯，看来现在再使用它正合适。同时我也建立了一个lessIsMore-ing的组织。
那么我可以 让 lessIsMore-ing来 fork我自己的learngit仓库，然后就可以模拟向开源代码 PR的情形了。
接下来我进行了如下测试。
- 测试只有一条
commit然后PR的情况 在fork的仓库下，新增一个文件，然后提交上传，最后进行PR，过程如下。fork仓库提交代码, 然后PR，见下图
upstream仓库 进行 MR，见下图.
upstream仓库的 commit记录增加了两条，一条 fork仓库的 84aedf, 一条为 MR的操作 99f017d
这个是完全符合预期的。
- 测试只有一条
commit然后PR的情况 在fork仓库下建立两条commit然后进行PR操作，过程如下。 fork 仓库提交两次commit,然后PR
upstream仓库 进行 MR.
此时会给我们三个选项分别为Create a merge commit 、 Squash and merge、Rebase and merge 我们一个一个实验,
我们先选择第一种Create a merge commit，建立普通的MR,让所有的commit保留.
然后再观察upstream仓库的commit记录，和第1步的记录类似，如下。
此时当我们再次 PR的时候，并未出现显示已经MR过的commit的情况。
- 我们继续再次重复步骤
2的过程，这次我们MR的方式采用Squash and merge. 省略commit和PR过程，直接看MR。
然后再观察
upstream仓库的commit记录
比着刚才的commit记录，只多了一条MR信息。我们的commit记录都被抹去了。
此时当我们再次 PR 的时候，会出现显示已经MR过的commit的情况。
嗯，看来这个就是出现重复commit情况的原因了。 为了保持严谨，我们继续实验第三种MR的情况，然而此时已经产生冲突，无法进行 Rebase and merge。
为了能继续实验Rebase and merge，我们先在fork分支进行rebase把冲突解决掉，然后提交代码(由于此步相比于实验流程为多余操作，故省略)
- 我们继续再次重复步骤
2的过程，这次我们MR的方式采用Rebase and merge. 省略commit和PR过程，直接看MR
然后再观察upstream仓库的commit记录
我们可以发现，在MR过后，并没有MR的信息，只有我们提交的commit信息。
经过上面四步，我们可以确定产生提交github的PR时会显示已经被MR过的commit的原因是 upstream上游仓库在进行MR时采用了squash and merge策略，导致author的commit信息被抹除
如何解决
方法一：rebase
# in your local master
# rebase，如果有冲突，解决冲突
git rebase upstream/master
# --force 是因为和远端分支出现分歧，会被拒绝
git push origin master --force
其他方法
由于在网上查的其他方法，经过我的真机测试，都不能完全解决fork仓库向upstream仓库PR时会显示已经MR过的 commit问题，在此我就不写了。如果有小伙伴有其他办法也可以留言互动。
后记
在向开源仓库贡献代码时，由于出于对整体分支一致性和连贯性的考虑，很多仓库管理者都会优先考虑用squash and merge的形式处理PR, 因此我们学会如何处理上面的问题还是有一定的必要的。同时我们也一定要在提PR时，尽量处理好commit的信息，保证合并时的流畅性。
希望这篇文字能够帮助到你，Bye。
