将合并和未合并的上游请求合并到我自己的fork中，当我稍后稍后尝试将请求的分支转移到上游时，让我感到悲伤吗？

Question

那个标题令人费解，但情况本身并不那么复杂。

[我正在为其主分支A贡献一个开源项目。它有一个待处理的PR B，我希望很快将其合并到master中。我正在C中的我自己的分支中开发一些新功能，但是我需要在B中完成更改才能继续进行。我知道我可以merge B into C with no problems。问题是-当以后我想将B包含在C中时，这会带来麻烦吗？到那时，它们两个都可能彼此独立地合并在C中。那会创建不必要的多余提交吗？

Answer 1

我们唯一可以给出的答案是也许或取决于。

您可能会问：取决于什么？，这变得有些复杂。 Git本身没有PR。拉取请求本身（与此相关的分支）具有特定于任何一个特定托管提供者的详细信息。

确实具有，保持和交换的是commits。提交由原始哈希ID标识，每个存储库中的哈希ID始终相同。 GitHub，GitLab，Bitbucket等在Git之上构建，因此它们也保留和交换提交，但它们上也堆叠了许多精美的界面。使用命令行Git，我们可以使用特定的命令来执行特定的提交操作。借助Web界面，我们具有可点击的按钮，这些按钮通常运行晦涩的，未描述的命令（可能是许多单独的命令行命令），并且很难说出它们的作用。

但是，我们可以说这里至少包含三个存储库。您将其称为上游服务器，它可能托管在某些托管服务器上。在同一托管服务提供商上还有另一个分支-另一个Git存储库，您想知道的PR A存在于其中。在同一托管提供程序上有

your

分支，第三个存储库。您自己的计算机（例如笔记本电脑）上可能至少还有一个Git存储库。[如果从字面上合并来自PR B的提交，以便将其父作为此PR B的尖端提交的提交添加到存储库中，那么您已经添加了此PR的实际提交及其实际哈希到存储库和分支机构的ID（也许在笔记本电脑上，也许在托管服务器上）。但是，如果您使用

copies

PR B提交的操作，例如B或B或git merge --squash，那么您将得到different提交。一些网络托管clicky的“合并此”按钮可以制作此类副本，而不是使用原始副本。拥有原始存储库的人有一个类似的选择：他们实际上可以合并PR git cherry-pick的尖端提交。如果

they

从字面上进行合并，而you从字面上进行合并，则Git会尽力而为，尽力而为。但是，如果他们使用的是copies个提交的进程，则无论您是否还从此PR git rebase复制了这些提交，他们将拥有与您不同的提交集。当然，将PR B提交给上游的人都可以自行撤消它，并通过新提交重新提供它。 （确切的机制可能取决于托管服务器。）

所有这些都使我们回到了一个不太令人满意的答案：这取决于。