我正在开发一个项目，其中大多数开发人员都在使用功能分支，这些分支通过PR合并回master。一位开发人员决定在该仓库中创建一个分支，在其中创建分支并从那里进行PR。
我们观察到的行为是，合并他的PR将文件引入到master分支中（如预期的那样），但是合并来自功能分支的PRS似乎会消除它们。
Fork可以在上游仓库中重写历史记录吗？这是怎么回事？
答案 0 :(得分：1)
叉子可以在上游仓库中重写历史记录吗？
否。
这是怎么回事？
这还不太清楚：我们需要查看有问题的存储库以及您使用的过程。
像Vinyl Warmth noted in a comment一样，“ fork”不是Git东西，它是GitHub / Bitbucket /其他提供“增值”东西的网站。
始终牢记这一点：Git并不真正在乎分支名称。 Git关心 commits 。存储库中的分支名称仅用于标识提交-具体来说，是一个 specific 提交，Git然后将其称为该分支的 tip提交。重要的是提交。承诺是历史；历史不过是提交。分支名称仅用于查找该分支的 last 提交。每个提交都会记住其先前的提交- parent -并且Git从末尾开始并向后工作。
Git并不太在乎文件。 Git关心 commits 。每个提交都具有整个源代码树的完整，独立快照，因此提取一个特定的提交将使您获得该源代码树：文件随身携带。重要的是 commit 。
克隆存储库会复制 all （可到达的）提交，从各种名称（分支和标签名称）开始，然后向后进行。然后，您git checkout提交一个 specific ，这就是获取文件的方式。您获得的文件就是该特定提交中的文件。
git push的作用是将您的Git（您的 local 克隆）连接到其他Git。然后，您的Git会转移您没有的所有提交，并让他们的Git设置一些名称（通常是一些分支名称）以记住这些新提交的 last 。因此，我们实际上只关心存储库中的 commits （通过某些名称可以找到它）。
请牢记这一点，请注意，GitHub或BitBucket上的fork只是一个克隆，具有在Web服务中处理的一些额外功能。特别是服务器：
这是第一个特别重要的要点：由于该网站记住了新克隆的来源，因此该网站允许拥有的用户发出请求请求发给拥有原始邮件的用户。
让我们使用一些名称可以更轻松地跟踪正在发生的事情。让我们将原始存储库称为 O （对于原始存储库），将其称为前叉 F （对于前叉）。本质上，我们拥有的是： F 记住 O 。
这几乎就是所有内容！这只是另一个克隆。您为与某个仓库进行合作而创建的每个克隆，无论是 O 还是 F 的克隆，都是另一个克隆。如果Oscar克隆 O ，并且Oscar对Oscar的克隆进行了一些更改并运行git push origin，则Oscar会将Oscar的提交推送到 O ，因为Oscar的origin URL是 O 。如果Fred克隆 F 并进行了一些更改并运行git push origin，则Fred会将Fred的提交推送到 F ，因为Fred的origin URL是的URL。 > F 。
Oscar现在可以从已经存储在 O 中的一项提交中以 O 发出拉取请求（使用Oscar可能使用的某个分支名称）向上）到 O 中的另一个分支名称。同时，Fred可以从存储在 F （在 any 分支下）中的一项提交向 O 发送拉取请求。 Fred选择的名称，因为现在 F 的名称与 O 的名称无关！）。弗雷德这样做时，弗雷德在 F 中不在 O 中的提交将首先被复制到 O ，因此他们居住在 O 中，仅存储在 O 中的“拉取请求”名称下，而不存储在 O < / strong>。从本质上讲，这是唯一的区别：Oscar所做的提交直接进入 O ，并在 O 中带有分支名称，同时还具有拉当Fred提交的提交首先进入 F 时，然后在Fred提出拉取请求时进入 O 。目前，只能通过PR名称而不是某些分支名称来找到Fred在 O 中的提交。
如果Fred可以直接将其推到 O ，那么Fred并没有特别好的理由来打扰叉子 F 。也没有特别 bad 的理由 not 来烦扰 F 。如果尚未提出拉取请求，使用 F 会使同事获得Fred的工作稍微困难一些，但是使用 F 可以使对于Fred来说，他认为还没有准备好进行审查和请求请求等工作的临时名称要容易一些。