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

Question

贡献回购的普通GitHub流程是创建上游分支，在您进行更改的地方克隆本地副本，然后将其推回分支，然后创建PR以将您的更改合并到上游。

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

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

由于这是一个非常常见的工作流程，因此似乎应该有一些使用GitHub GUI进行操作的简单方法。

Answer 1

  

没有合并提交或使用CLI？

不能单独直接与GitHub Web UI一起使用，因为这涉及到在upstream/master

上对您的PR分支进行重新定位

简而言之：不。
但是短话短说...也许，如果您真的想尝试的话。

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

• 如果您是原始存储库的维护者，想集成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。
  含义：分支中的master代表更新后的upstream/master，其中upstream是您已创建的原始存储库。
• 由于您是该存储库（您的分支）的所有者，因此GitHub可以向您显示是否可以将所述分支重新建立为PR的基础分支（master），但前提是不存在冲突。
• 最后，再次将基础分支更改为<originalRepo>/master（这是PR的预定目标）

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

简而言之，它涉及：

• Bruno Skvorc来自您当前的master（在您分叉原始存储库时位于upstream/master）

creating a new branch

• 通过该新分支和<originalRepo/master>
进行PR
• 在创建PR之前进行基本切换

这是人为迫使upstream/master刷新的步骤

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

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

然后您可以继续上述步骤，并将当前PR的基础更改为您自己的（现在已刷新）master分支，并查看是否可以对其进行重新设置！

Answer 2

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

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

  在GitHub Desktop中：

  1. 从File > Clone Repository

  克隆您的存储库

  2. Fetch origin，它也会自动获取上游

  3. 通过点击Branches

  上的位置转到Current Branch

  4. 单击底部的Choose a branch to merge into <branch>

  5. 搜索upstream/<branch>，然后单击Merge upstream/<branch> into <branch>

  6. 推到起源，等等！

• 否则，如果当前分支已经在派生分支之前提交了，那么当然必须创建一个合并提交或变基并强制推送。要进行更佳的变基，请执行以下操作：

  1. 在GItHub Desktop中，从菜单转到Branch，然后依次转到Rebase Current Branch

  2. 搜索upstream/<branch>，然后单击Start Rebase

  3. 解决由于重新设置而发生的所有冲突

  4. 强制压入原点。出于明显的原因，您将因此得到警告。

为避免在当前分支位于上游分支的前面和后面时强行推动工作，请创建新的合并提交或：

• 根据您的所有更改创建新分支

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

• 执行第一个方案中的步骤并将您的更改合并到分支中。

是的，目前看来不可能通过GitHub网站从原始存储库中进行拉取而无需创建拉取请求和合并提交 。

---

第一种情况的演示GIF：https://imgur.com/a/8wci2yf

与此相关的一些GitHub问题：

• Add an upstream to forked repositories

• multi-remote support in Desktop

Answer 3

应避免使用某些做法。

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

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

您可以在feature_branch中工作，然后提出“拉取请求”。

• 一旦您的更改被合并到上游主服务器中，就可以从上游拉到您的原点。由于上游的主服务器将您的提交整齐地放在其顶部，因此不会有合并提交。

$ git checkout master
$ git pull upstream master
$ git push origin 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

Answer 4

要正确回答此问题，重要的是要了解您将要实现什么。我想您希望1）保持历史记录清晰，或者2）通过保持提交不会被合并中断来简化diff。

如果我的理解是正确的，请使用 rebase 。