为什么github上创建一个岔路提交树时，壁球和合并

Question

我有以下的历史在我的叉：

x feature & origin/feature 
| 
x upstream/feature 

然后我做了一个拉请求，这是成功压扁&合并。当我拉从上游的变化，我的历史是这样的：

x upstream/feature 
| x feature & origin/feature 
|/
x 

我期待下面：

x feature & origin/feature & upstream/feature 
| 
x 

所以是GitHub上的预期行为拉请求或我搞砸的东西了？

Answer 1

GitHub的“压扁和合并”按钮始终创建一个新的提交，该提交包含在拉取请求中应用每个提交的结果。 （更准确地说，它会创建一个新的提交，它使用合并行动 - “合并为动词”，但是让一个普通的，非合并提交这也是什么命令行git merge --squash一样。）

当有一个只有一个在提交请求中提交，这使得一个提交的副本。

如果有两次提交你：

* (upstream/feature) the squash commit that is not a merge 
| * (feature, origin/feature) commit 2 
| * commit 1 
|/ 
* the common base across your GitHub repo and their GitHub repo 

注意，如果上游回购使用真实的合并，曲线几乎是一样的，只不过它的内容：

* (upstream/feature) the merge commit that IS a merge 
|\ 
| * (feature, origin/feature) commit 2 
| * commit 1 
|/ 
* the common base across your GitHub repo and their GitHub repo 

无论哪种方式，如果你打算使用合并或合并（即不合并，但是压扁）提交，你应该移动你自己的分支来指向他们的提交，并忘记你的一系列提交。如果上游人员进行了壁球合并，这可能很困难：您必须得到整个球队的放弃他们的feature版本并切换到上游的feature,的提示提交，即使这意味着失去您自己的提交。如果上游人员确实合并了您的提交，则更容易：您可以简单地允许Git从feature的顶端向上游feature执行不实际合并的快速“合并”。