如何从分叉的仓库更新拉取请求？

Posted 2023-02-19

【中文标题】如何从分叉的仓库更新拉取请求？

【英文标题】：How to update a pull request from forked repo?

【发布时间】：2012-04-05 03:14:53

【问题描述】：

所以我首先分叉了一个 repo，然后对该分叉的 repo 进行了提交。然后我打开了一个拉取请求。拉取请求列出了我想要的所有更改。

在查看了我的拉取请求后，回购所有者希望我在接受之前进行一些更改。我已经在我的 fork 中进行了这些更改，现在如何使用这些更改更新拉取请求（或者这不是我应该如何处理它）？

【问题讨论】：

Preferred Github workflow for updating a pull request after code review的可能重复

@PaulDraper 我不同意，该用户已经知道并提出了各种更新拉取请求的方法，并询问哪种方法最好。另一方面，我不知道任何方法，并且正在询问它们的存在。正如这个问题的受欢迎程度所示，许多其他用户也是如此。

我认为受欢迎的原因在于 (1) 这是一个非常好的常见问题，以及 (2) 一些用户在这里而不是那里结束。如果它最初被识别为重复，他们会发现另一个问题是相同的并回答他们的问题。

【参考方案1】：

只需推送到拉取请求引用的分支。只要拉取请求仍然打开，它应该会自动更新任何添加的提交。

【参考方案2】：

你做得对。拉取请求将自动更新。流程是：

打开拉取请求 根据本地存储库中的反馈提交更改 推送到 fork 的相关分支

拉取请求会自动将新提交添加到 PR 的 Commits 选项卡。

【讨论】：

不错！除了实际的拉取请求，我到处检查。它的魔法，黑魔法，我不会质疑它。

这是在分支机构工作的好理由。例如，如果您总是推送到 master，您可能会无意中添加到之前的拉取请求中。

这似乎不再是这种情况，尽管它是过去。这是我提出的拉取请求 (github.com/toopay/bootstrap-markdown/pull/167) 与分支本身 (github.com/mhuggins/bootstrap-markdown/commits/…) 相比的示例。好奇如何再做这件事，因为这个过程似乎已经改变了。

GitHub 实际上告诉你：“通过推送到 ChangeTheWorldProject 上的 SolveWorldHunger 分支添加更多提交。”

这里也一样 - 我在主存储库中看不到来自分叉存储库的更改。看起来像一个 GitHub 错误

【参考方案3】：

如果在 Windows 上使用 GitHub：

在本地进行更改。 打开GitHub，切换到本地仓库，双击仓库。 将分支（窗口顶部附近）切换到您从中创建拉取请求的分支（即比较的 fork 侧的分支） 应该会看到在右侧输入提交评论并将更改提交到本地存储库的选项。 单击顶部的同步，其中包括将您的提交从本地推送到 GitHub 上的远程分支。 拉取请求将随其他提交自动更新。这是因为拉取的请求代表了与您的 fork 分支的差异。如果您进入拉取请求页面（您和其他人可以对您的拉取请求发表评论的页面），那么“提交”选项卡应该有您的额外提交。

这就是为什么在您开始进行自己的更改之前，您应该为您计划放入拉取请求的每组更改创建一个分支。这样，一旦您提出拉取请求，您就可以创建另一个分支并继续处理其他一些任务/功能/错误修复，而不会影响之前的拉取请求。

【参考方案4】：

在 GitHub 中更新拉取请求就像将想要的更改提交到现有分支（与拉取请求一起使用）一样简单，但通常还希望将更改压缩到单个提交中：

git checkout yourbranch
git rebase -i origin/master

# Edit command names accordingly
  pick   1fc6c95 My pull request
  squash 6b2481b Hack hack - will be discarded
  squash dd1475d Also discarded

git push -f origin yourbranch

...现在拉取请求只包含一个提交。

---

关于变基的相关链接：

https://help.github.com/articles/about-git-rebase Squash all my commits into one for GitHub pull request

【讨论】：

赞成提到变基。它有助于消除修订历史中的噪音。

+11（是的，我打算使用 rrrrepeating 键。使用 git rebase/pick/squash 效果很好。

这种方法的缺点是您正在删除之前的提交。这意味着如果在拉取请求中创建了 cmets，它们将丢失，并与原始提交一起消失。

在 Bitbucket 中，您可以在拉取请求中查看文件“先前版本”的 cmets。尽管在 Gerrit 中看到类似的东西会很好，您可以在其中修补提交并可以使用 cmets 查看整个历史记录。当您可以返回并查看围绕任何提交的完整讨论时，它可以提供简洁的 git 历史记录和可追溯性。

【参考方案5】：

我是按照以下步骤完成的：

git reset --hard <commit key of the pull request> 我是否对我想做的代码进行了更改 git add git commit --amend git push -f origin <name of the remote branch of pull request>

【讨论】：

很好，我更喜欢这种方式！ GitHub 甚至隐藏（但保留）过时的代码部分和相关的 cmets。请记住，如果拉取请求包含多个提交并且需要修复的提交不在分支的顶端，“git reset --hard”将丢弃在指定 ID 之后提交的所有更改。我有一个手动应用的备份。如果有不止一个额外的提交，那就不太方便了......