如何在 GitHub 上打开多个拉取请求答案

【问题标题】：How to open multiple pull requests on GitHub如何在 GitHub 上打开多个拉取请求
【发布时间】：2012-01-17 00:19:51
【问题描述】：

当我在 GitHub 上打开 拉取请求。
自我上次请求以来的所有提交以及所有新提交都会自动添加到此请求中。

我似乎无法控制添加哪些提交，哪些不添加。
当我尝试打开另一个拉取请求时，我收到“糟糕！已经有拉取请求”错误。

有什么简单的方法可以打开多个拉取请求，而不必乱用命令行？

【问题讨论】：

标签： git github pull-request

【解决方案1】：

拉取请求基于分支。
为多个提交打开拉取请求的唯一方法是：

将它们隔离到它们自己的分支。
从那里打开拉取请求。

【讨论】：

好吧，这很酷，我还以为只有大师才有。所以你的意思是我可以创建许多分支（即：git flow features）并为每个分支发出请求......去试试！
我刚刚发现分支保留了之前提交的历史记录，所以针对上游的拉取请求仍然包含所有提交。
嗨@eel-gheez，你知道该怎么做吗？如何在不显示来自其他分支的更改的情况下创建独立的 PR？
这并不能解决问题：当我尝试创建 PR 时，会比较两个分支（每个分支至少有一个提交）。我做错了什么？
@eelghEEz 你应该创建一个新分支，git cherry-pick 你想要的所有提交到这个分支，然后从这个分支发出一个拉取请求。 git 的一个非常重要的设计特性是每次提交都依赖于它之前的提交，并且 git 中的提交不应该只是一个补丁，而是一个知道在此之前应用了什么补丁的补丁。所以这就是为什么人们应该创建一个带有新提交的新分支，其差异可能仍然相同，但与之前提交的链接不同。

【解决方案2】：

我发现最简单的方法是使用 hub 命令 (https://github.com/defunkt/hub)。

从您要为其创建拉取请求的主题分支（本例中为“功能”），您可以运行：

git pull-request

（记得先推送你的分支！）

它会在 GitHub 上为“YOUR_USER:feature”打开一个新的拉取请求。

如果您已经在 GitHub 上创建了问题，您甚至可以将拉取请求附加到该现有问题（您无法从 Web UI 执行此操作）：

$ git pull-request -i 123
[ attached pull request to issue #123 ]

【讨论】：

【解决方案3】：

您可以通过为您的工作创建单独的分支来创建 Pull Request(PR)。

例子：

您从分支 master 结帐到分支 work-1。
您在分支 work-1 中以 work-1-commit-1 和 work-1-commit-2 进行了一些提交
现在您创建了一个从 work-1 到 master 的 PR。可以通过查看 PR 更改的文件来审查您的代码。
现在，为了进一步的工作，您将从分支 work-1 结帐到新的分支 work-2
您在分支 work-2 中以 work-2-commit-1 和 work-2-commit-2 进行了一些提交
现在您创建了一个从 work-2 到 work-1 的 PR。可以通过查看从 PR 更改的文件来审查您的代码。

这里的文件更改将只有您之后编写的新代码 work-1-commit-2。

【讨论】：

这与@markwisinich 描述的流程相同，但更清晰一些。

【解决方案4】：

您实际上可以在不创建另一个分支的情况下执行此操作，但需要一些时间。
步骤如下：

确定要提取的两个提交范围。这是我将用作示例的内容：
（其他/主人）A -> B -> C -> D -> E（你的/主人）
假设您想在一个请求中拉取 B 和 C，在另一个请求中拉取 D & E。
发出拉取请求。将左侧（“Base”）作为提交 A。对于右侧（“head”），输入 C 的提交编号。
为您的第一个请求编写说明。
提出另一个请求。对于基础，输入 C 的提交编号，对于头部，输入 E（你的/主人）。
写下描述。

在我看来，拉取请求将提交 C 视为一个分支点。什么的。

【讨论】：

您必须将 other/master 保留在左侧，即使您要添加来自 yours/master 的提交编号。此外，此方法不允许您向合并请求添加新提交，以防需要进行更多更改。
我在这个答案上发布了一些跟进，与 Github 上的一些信息形成对比，请参阅 stackoverflow.com/questions/23159860
我可以看到这会创建两个看起来正确的 PR，因为它们每个都包含所需的提交。但是，明确地说，当它们合并时它做正确的事情吗？如中所示，我可以看到第一个 PR 会正确地将 B & C 合并到 other/master 中。但是当第二个 PR 合并时，它怎么知道要合并到哪个分支呢？（因为它是在提交“C”上创建的，而不是在其他/主服务器上创建的）PR 合并的顺序是否重要？（大概是这样）

【解决方案5】：

当您最初创建拉取请求时，如果您为新的拉取请求打开两个单独的表单，只要它们指向要合并的不同分支，您就可以创建它们。例如，我可以发出两个单独的请求，一个合并到 master，另一个合并到 test。

【讨论】：

【解决方案6】：

我是 Git 和 GitHub 的新手，和 OP 有同样的问题。

我找到了一个解决方案，可能在 OP 时不可用。

情况：您有 3 个更改，并且您希望每个更改都建立在前一个更改的基础上，并且每个更改都有自己的拉取请求 (PR)。

问题：当您创建第一个 PR 尝试将 develop 拉入 master 时，一切看起来都很好，但是在您对第二个 PR 进行更改并合并它们（使用相同的分支）之后，所有更改都在同一个公关。

迷你解决方案：创建一个新分支

git branch mini_change_2
git checkout mini_change_2

现在你将代码推送到 GitHub 并创建 PR，但它默认从 mini_change_2 拉到 master，除了 master 还没有第一个 PR 的更改，所以它包含了 PR1 和 PR2 的所有更改。

最佳解决方案：在 PR2 中指定要合并到的分支。

在创建第二个 PR 时不要只接受默认值，比如说你要将 mini_chnage_2 拉到 Develop，这只会显示 mini_change_2 中的更改

现在创建一个新分支 mini_change_3 并将其 PR 到 mini_change_3。

一旦你开始合并它们，问题就来了……但这是一个不同的练习。

【讨论】：

我相信你有一个错字，你说“现在创建一个新的分支 mini_change_3 并将其 PR 到 mini_change_3。”，你的意思不是“现在创建一个新的分支 mini_change_3 并将它的 PR 到 mini_change_2 。” ?

【解决方案7】：

如果你不是跨叉工作的话，今天才发现这个：

转到您在 GitHub 中的分支
点击“比较”按钮
更改要比较的基本分支
点击“创建拉取请求”
???
利润

【讨论】：

【解决方案8】：

如果你进入仓库页面，点击 Pull Requests，有一个“New pull request”按钮，你可以使用它在任意两个分支之间创建 pull request。

这对于必须合并到主分支和开发分支的修补程序非常有用（在不同的时间，取决于您如何部署系统）

【讨论】：