【发布时间】：2023-03-24 01:40:01
【问题描述】：
是否可以修改其他人发起的拉取请求？
假设我维护项目 X，并且用户 A 向我发送了拉取请求。有些事情我想在合并之前进行更改，并且可以自己快速完成。我怎样才能简单地做到这一点并将其全部保存在一个 PR 中？
这可能吗？
【问题讨论】：
【发布时间】：2023-03-24 01:40:01
【问题描述】：
有可能！您所要做的就是检查他们拉取请求中的分支并进行所需的更改。在您提交并推送这些更改后，它们应该会反映在 Github 的拉取请求中。
【讨论】：
-
对于未来的读者：除非我弄错了，否则您只能在分支位于主存储库中时执行此操作。考虑尝试将
contributor/feature合并到original/master作为original/master的所有者——除非contributor——提交公关的人——给你推送访问他/她的权限，否则你将无法推送到contributor/feature存储库。
假设您对用户的 github 存储库具有读取和写入访问权限，您可以推送到拉取请求来自的分支。
它位于拉取请求的底部，在 MERGE PULL REQUEST 按钮之前。
您可以通过推送到 yyyy/zzzzz 上的 XXXXX 分支向此拉取请求添加更多提交
【讨论】：
你可以这样做：
在您的仓库中，
git checkout -b new-branch
然后将用户 A 的提交拉入您的新分支：
git pull git://github.com/[User A]/[project-name].git
之后，您可以在新分支中随意更改它。当您测试并满意您的更改时，您可以将其合并到您的主分支中：
git checkout master
git merge new-branch
好的，现在您有了用户 A 的代码和您的更改。
【讨论】：
-
如果您不想拉出用户的主分支，而是想拉出树中的某个其他分支怎么办？ stackoverflow.com/questions/1709177/…
-
分支名称是
git pull的可选第二个参数 -
我认为
git fetch upstream pull/<pull id>/head:<new-branch>比 git pull 来拉 PRs 更好。 -
当我最终将 master 推回原点时，这是否会关闭 GitHub 的 PR？是否足够聪明地理解我合并的内容（用户 A 的更改 + 我的）实际上包含拉取请求中的内容？编辑：我的意思是，如果我这样做，它会将 PR 标记为在 GitHub 上合并吗？ （当拉取请求中的更改是合并内容的子集时）。
-
“当我最终将 master 推回原点时，这是否会关闭 GitHub 的 PR？”
不可能，但您可以向他们的分支提交第二个拉取请求，如果他们决定合并原始拉取请求，它将更新原始拉取请求。
【讨论】：
很遗憾，不，以下方法不起作用：
git push -f upstream my-updates:refs/pull/999/head
...
! [remote rejected] my-updates -> refs/pull/999/head (deny updating a hidden ref)
error: failed to push some refs ...
【讨论】：
-
确实如此。 Github 文档中描述了这种行为：help.github.com/articles/checking-out-pull-requests-locally/…
我意识到这是一个老问题，但 GitHub 最近引入了一些新功能，可以实际更新其他用户提交的拉取请求。
当您创建新的拉取请求时，您会看到一个标有“允许维护者编辑”的复选框。这是默认启用的。
有了这个，任何对作为您的拉取请求的目标存储库的提交访问权限的人也将能够将更改推送到您的存储库的分支这就是拉取请求的来源。
这在团队环境中特别有用，在这种环境中，每个人都可以提交对“主”存储库的访问权限，但所有工作都在各个分支中的功能分支上完成。这意味着如果有一个开放的 PR 需要一些更改并且主要作者不可用，团队中的其他人可以直接进行必要的更新，而不是关闭现有的 PR 并打开一个新的。
【讨论】：