GitHub PR 为什么不建议压缩与合并长运行分支?

Question

官方文档中描述如下：

压缩与合并长运行分支

如果计划在合并拉取请求后继续操作头部分支，建议不要压缩与合并拉取请求。

在创建拉取请求时，GitHub 会标识头部分支和基础分支上的最新提交：共同的提交原型。 在压缩与合并拉取请求时，GitHub 会在基础分支上创建提交，其中包含自提交原型以来对头部分支所做的所有更改。

由于此提交仅位于基础分支而不是头部分支上，因此两个分支的共同原型保持不变。 如果您继续使用头部分支，则在两个分支之间创建新的拉取请求，该拉取请求将包含自共同原型以来的所有提交，其中包括你在之前的拉取请求中压缩与合并的提交。 如果没有冲突，您可以安全地合并这些提交。 但是，此工作流会增大合并冲突的可能性。 如果您继续压缩与合并长运行头部分支的拉取请求，则必须反复解决相同的冲突。

请问如何理解"但是，此工作流会增大合并冲突的可能性。如果您继续压缩与合并长运行头部分支的拉取请求，则必须反复解决相同的冲突"?

Answer 1

其实原因都画在了那个图示上了。

Squash merge的作用是将多条commit记录合并成一条（你可以理解为git reset xxxx之后再git commit，将commit log合并成一条新的），然后push 到主分支上。对于主分支来说会让分支图很好看，一个PR最终只会生成一个commit log,不会出现蛇形的分支图。如果参与开发的人不算多的话，比如个人项目，其实我还挺建议使用这种方案的。

但是对于下游的用户来说就比较麻烦了，尤其对于git新手，会忙于解决上游的冲突。以发起PR的人为例。他那么多条commit log在PR合并之后变成一条了，等于他本地的分支图和远程的仓库相比发生了偏离，那么他必须纠偏之后才能进行下一次PR，这个纠偏操作对于新手来说还是很有很有难度的。

一般来说可能需要用到git pull --rebase或者git reset后重新修正本地分支图之后再进行操作。而采用默认的merge策略的话，则会生成一个Merge from的commit之后提交到主分支，那么下游只需要git pull就能同步，难度一下低了一截，但是可能会让中央仓库的分支图特别丑，有commit洁癖者(比如我)一般都难以接受

与之类似的策略还有个rebase merge，也就是fast forward only合并策略，你可以理解为git pull --rebase这种操作，不会生成Merge from的记录，不会变蛇形分支图，保留用户的commit log.可以说兼顾commit log和分支图的方案。不过github的这个策略很傻，会改sha1码，也就是它内部的实现相当于把这些commit log重新commit --amend了一遍，也会造成分支图偏离，原因不明。但是其他平台比如gitlab这种rebase merge的策略就是符合期望的，我们的gitlab就用的是rebase merge策略合并MR的

Answer 2

结合 SO 这个问题的回答算是搞懂了。
git merge squash and recurring conflicts