为什么github在squash＆amp; merge时会在提交树中创建一个fork

Question

我的叉子中有以下历史记录：

x feature & origin/feature
|
x upstream/feature

然后我做了一个成功压扁的拉动请求＆amp;合并。当我从上游提取更改时，我的历史记录如下：

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

我期待以下内容：

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

github pull请求的预期行为是什么，或者我搞砸了什么？

Answer 1

GitHub的“squash and merge”按钮始终创建一个新的提交，其中包含在pull请求中应用每个提交的结果。 （更准确地说，它创建了一个使用合并操作的新提交 - “合并为动词” - 但是进行普通的非合并提交。这也是命令行{{1}确实。）

如果拉请求中只有一个提交，则会生成一个提交的副本。

如果有两个提交：

git merge --squash

请注意，如果上游repo使用true merge，则图表几乎相同，只是它显示为：

* (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

无论哪种方式，如果你打算使用merge-or-“merge”（即不合并但是压缩）提交，你应该移动你自己的分支指向他们的提交并忘记你的一系列提交。如果上游人员进行了南瓜合并，这可能很困难：您必须让您的整个团队放弃他们的* (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 版本并切换到上游{{1}的提示提交}，即使这意味着丢失自己的提交。如果上游人员合并你的提交，那就容易多了：你可以简单地允许Git从feature的尖端执行一个非实际合并的快进“合并”上游feature。