如何在没有合并提交或使用 CLI 的情况下使 GitHub 分叉保持最新？

Posted 2023-02-18

【中文标题】如何在没有合并提交或使用 CLI 的情况下使 GitHub 分叉保持最新？

【英文标题】：How to keep a GitHub fork up to date without a merge commit or using CLI?

【发布时间】：2019-10-17 22:45:07

【问题描述】：

贡献代码库的正常 GitHub 流程是创建上游的分支，克隆您进行更改的本地副本，然后推送回您的分支，然后创建 PR 以将您的更改合并到上游。

但是如果在那之后上游发生了变化，你如何在不创建合并提交的情况下更新你的 fork（并且也不使用 git CLI）？

我已经知道如何以创建合并提交或依赖 git 命令行界面的方式执行此操作。此问题专门针对仅使用 GitHub.com 网站或 GitHub Desktop 应用程序（无 CLI）。

由于这是一个非常常见的工作流程，似乎应该有一些使用 GitHub GUI 的简单方法来完成它。

重申一下：任何使用 CLI 或创建合并提交的答案（例如 this way）都不会回答这个问题，因为我正在明确寻找非 CLI 解决方案。

【问题讨论】：

我知道用使用 CLI 的答案来回答这个问题非常诱人。这有一个赏金的原因是因为我明确地不寻找使用 CLI 工具的答案。看看git 是如何未被标记的：这是故意的。另外，我知道通过许多步骤，您可以使用 GitHub.com 网站从上游拉取，但这会创建一个合并提交，这是我明确不寻找的另一件事。

【参考方案1】：

没有合并提交或使用 CLI？

不直接使用 GitHub Web UI，因为它会涉及在upstream/master 之上重新定位您的 PR 分支

简而言之：没有。 但总之……也许，如果您真的想尝试一下。

实际上可以通过 GitHub Web UI 进行变基，since Sept. 2016，...

如果您是原始 repo 的维护者，想要集成 PR 分支 如果重放的提交都没有引入冲突

（这与GitHub Desktop 不同，因为June 5th 2019 确实支持变基。但这是Git CLI 的前端，就像其他工具提供的一样。例如GitKraken and interactive rebase）

所以一个复杂的解决方法是：

获取，然后将 upstream/master 推送到您自己的 fork 的 master 分支（一个 CLI 操作，但更多内容见下文） change the base branch of your current PR 到 master（所以同一存储库中的 PR：您自己的 fork），前提是您尚未推送到 master。 含义：fork 中的master 代表更新后的upstream/master，upstream 是您fork 的原始存储库。 由于您是该存储库（您的 fork）的所有者，GitHub 会显示您是否可以将所述分支重新设置为 PR 的基础分支 (master)，但前提是不存在冲突。李> 最后，再次将基础分支更改为 <originalRepo>/master（这是您 PR 的预期目标）

第一步通常是通过命令行完成的，但是...可能有一个技巧可以通过 Web UI 来完成它（在你的 fork 中更新上游 master）：参见 Bruno Skvorc 的“Quick Tip: Sync a Fork with the Original via GitHub’s Web UI”

简而言之，它涉及：

creating a new branch 来自您当前的 master（在您分叉原始存储库时将位于 upstream/master）

使用该新分支和<originalRepo/master> 进行 PR

基础切换

在创建 PR

这是人为强制刷新upstream/master的步骤

您可以使用“合并拉取请求”按钮（以及之后的“确认合并”）创建和合并它：合并将是微不足道的：没有合并提交。

最终结果是：您自己的 master 分支（在您的 fork 中）更新为 upstream/master（原始存储库的 master 分支）！

然后您可以恢复我上面描述的步骤，并将您当前 PR 的基础更改为您自己的（现已刷新）master 分支，看看您是否可以重新设置它！

【讨论】：

如果我没看错的话，fork 永远不会以这种方式更新，所以随着时间的推移，fork 会变得越来越过时，以至于 rebase 合并会变得疯狂.

这太聪明了，顺便说一句，感谢您思考如何做到这一点。

@brentonsrine 不，fork 更新了：更准确地说，fork 的 master 分支（代表上游/master 分支的原始状态）首先更新，然后你 rebase 你的 PR 分支。

它不起作用。它仍然是三种可能性：两种创建合并提交和“Rebase and merge”，即使我没有更改分叉主控中的任何内容，也存在冲突。

@int_ua 好的，如果你在那里找到解决方案，请告诉我，我不监控 webapps，只监控 Stack Overflow（那里有 40000 多个 GitHub 问题，而 webapps 上有 371 个问题）

【参考方案2】：

考虑到以下几点，这对于 GitHub Desktop since version 1.0.7 是可行的：

如果当前分支在上游没有任何提交（fork 的原始 repo），则可以在不创建新合并提交的情况下拉取新提交

在 GitHub 桌面中：

从File > Clone Repository克隆您的存储库

Fetch origin，也会自动获取上游

点击Current Branch，转到Branches

点击底部的Choose a branch to merge into <branch>

搜索upstream/<branch>，然后点击Merge upstream/<branch> into <branch>

推到原点，等等！

否则，如果当前分支在 fork 之前有提交，那么当然必须创建合并提交或变基并强制推送。对于可能更可取的变基，请执行以下操作：

在 GItHub Desktop 中，从菜单转到 Branch，然后转到 Rebase Current Branch

搜索upstream/<branch>，然后点击Start Rebase

解决从 rebase 发生的任何冲突

强制推送到原点。出于显而易见的原因，您将收到警告。

当您当前的分支在其上游分支的前面和后面时，为了避免强制推送到您的工作，请创建一个新的合并提交或：

根据所有更改创建一个新分支

如果需要，将原始分支重置为其原始状态（在它偏离原始存储库之前）

执行第一个场景中的步骤并将您的更改合并到您的分支中。

是的，目前看来，在不创建拉取请求和合并提交的情况下通过 GitHub 网站从原始存储库中拉取 是不可能的。

---

第一个场景的演示 GIF：https://imgur.com/a/8wci2yf

与此相关的一些 GitHub 问题：

Add an upstream to forked repositories

multi-remote support in Desktop

【讨论】：

你有没有尝试过这种方法？有任何问题或意见吗？按照说明，这似乎是一个漫长的过程，但实际上需要大约 30 秒才能完成。

您是否先点击了 Fetch @brentonsrine？有一个链接的 GIF 向您展示如何从那里进行操作。你有最新版本的 GitHub Desktop 吗？

是的，这就是问题所在，刚刚意识到并删除了我的评论。

没问题@brentonsrine。如果有什么我可以做的来澄清这些步骤，请告诉我。

从 1.0.7 开始，变基功能真的可用吗？我知道 2.0（在提出这个问题几天后发布）进行了大修以帮助重新设置基准 - 在 2.0 之前，我不知道重新设置基准的能力。

【参考方案3】：

更新 注意：基于非 CLI 的方法可能会有所帮助： Is there a way to make GitHub Desktop rebase a branch against master?

这里唯一的关键是做一个变基，所以上面的答案应该会有所帮助。

---

CLI方式（更简单，使用git，所以默认应该更全面）

您应该使用一些做法来避免这种情况。

不要在你的 fork 中的 master 分支上工作。

$ git clone <your fork>
$ git checkout -b feature_branch

您可以在 feature_branch 中工作，然后提出 Pull Request。

在上游主服务器中合并您的更改后，您可以从上游拉取到您的来源。由于上游的 master 会将您的提交整齐地放在它上面，因此不会有合并提交。

$ git checkout master
$ git pull upstream master
$ git push origin master

如果维护者与您的分叉中的主服务器发生了分歧，也就是说，它不再是线性的，您需要提取它的新副本。这应该不是问题，因为您的更改已经在上游。

如果上游的 master 在你处理 PR 时已经前进，那么你可以重新定位你 feature_branch。

$ git checkout master
$ git pull upstream master
$ git push origin master
$ git checkout feature_branch
$ git rebase master

详细参考本文档：Fork and pull request workflow

【讨论】：

CLI 表示命令行界面。因此，您的答案中以$ 开头的所有行都是CLI。我试图让我的问题非常清楚，我不是在寻找 CLI 解决方案。你能给我一些建议，让我更清楚我不是在寻找 CLI 解决方案吗？

有一种方法可以使用 Github Desktop 进行变基，所以这可能会有所帮助。我通常避免使用 UI，因为它使事情变得有点复杂。我使用 UI 的唯一原因是在提交时部分选择行并将现有提交分解为较小的行，因为这在 CLI 中有点困难。

@brentonsrine 很清楚。出现这个特定答案的原因很可能是由于赏金。最高投票的答案，如果至少有 2 个投票，如果在期限结束后没有选择任何答案，则获得一半的赏金代表，所以如果这个答案是最高投票的一个......（参考：meta.stackexchange.com/questions/16065/…）。在这种情况下，最好的办法是如果这个答案不能解决您的问题，请投反对票并继续前进。

为 pikaynu 辩护，他们在我创建赏金之前发布了答案。

为我辩护，是的，我没有看到赏金，也没有为赏金发帖。谢谢@brentonsrine。 :)