澄清 GitHub 的拉取请求如何工作和一般合并。必须做什么？答案

【问题标题】：Clarification with how GitHub's pull request works and merging in general. What must be done?澄清 GitHub 的拉取请求如何工作和一般合并。必须做什么？
【发布时间】：2019-06-05 06:44:40
【问题描述】：

最近，我们一直在将主题分支合并到我们的开发分支。事情是这样的：在主题分支被合并到开发分支之后（通过pull request），需要向该主题分支引入新的更改以解决一些问题。

是否可以发布另一个pull request 并让 git 完成其余的工作（基本上，所说的主题分支被合并 2 倍，甚至更多，到开发分支），或者 resetting PR 并重新发布 PR 是必要的为了不把事情搞砸？（好像我们已经采取了这条路线，只是想澄清一下这是否有一些隐藏的副作用）。

如果reset 不可行，cherry-picking 会是更好的解决方案吗？

谢谢。

编辑#1：

似乎cherry-picking 比通常的过程工作得更好，但是，我担心它对正常合并过程的影响。

【问题讨论】：

我建议只分支目标，修复错误，然后发出新的拉取请求。
@TimBiegeleisen 目标是开发分支？另外，您对上述场景还有其他意见吗？

标签： git github pull-request git-reset git-cherry-pick

【解决方案1】：

如果你的开发分支在 PR 后没有新的提交，可以reset 重新做 PR。这样可以使您的提交历史记录比其他解决方案更干净

在 dev 分支上发生新提交后重置意味着您丢失了这些新提交，因此不建议这样做。在这种情况下：

从主题分支中挑选问题修复
为问题修复创建一个新分支（Tim 的建议）
从主题分支创建第二个 PR

都是可行的解决方案。

以上都不会为您提供提交历史记录（在开发分支上），其中与主题分支相关的所有提交都在一起。为此，您需要rebase

【讨论】：

从主题分支创建第二个 PR 是否意味着，添加提交以解决该主题分支上的问题（已合并），然后有效地发出另一个 pull request合并该一（1）个主题分支至少两次？正确的？如果这是正确的，请注意这已经是我们正在做的事情......我现在的问题是......它安全吗？理想的？安全吗？
是的，它是安全的。在这种情况下，没有普遍的“理想”选择。如果您为开发分支使用基于 PR 的工作流程（因此不允许挑选樱桃），请选择 Tim 的建议，或者继续您正在做的事情。