前一个未决合并时的新拉取请求答案

【问题标题】：New Pull Request when a previous one is pending Merge前一个未决合并时的新拉取请求
【发布时间】：2022-01-24 13:00:27
【问题描述】：

我在一个新分支（我们称之为branch_a）上对项目的几个文件进行了一些更改，我提交了它们，创建了Pull Request，它最近得到了审查和批准。它仍在 master 分支上等待合并。

现在，有人要求进行另一项更改。这是对第一个 Pull Request 中编辑的文件的一个小的补充更改。

这样做的最佳方法是什么？我是否应该要求合并第一个拉取请求，然后创建一个新分支（branch_b），进行更改并创建一个新的拉取请求，请求审查并再次合并？还是有一种“更干净”的方式，当第一个 Pull Request 以某种方式与第二个合并时，我们不必进行 2 次不同的合并？

【问题讨论】：

拉取请求是 GitHub（或 Bitbucket）功能；它们的精确行为取决于托管站点（GitHub 或 Bitbucket 或任何其他站点也可能将它们添加的内容称为“拉取请求”）。我已经更新了你的标签。

标签： github

【解决方案1】：

分支出第一个拉取请求分支，编辑、添加、提交、推送并请求第二个 PR 合并到第一个分支。当第一个分支合并时，第二个 PR 将自动重新配置（通过 GitHub）以合并到主分支中。

【讨论】：

【解决方案2】：

如果请求的另一个更改是与“branch_a”中相同功能的一部分，那么您只需在同一分支中进行更改，您的 PR 请求将显示这些更改，但需要再次 PR 批准。

如果请求的另一个更改超出了功能“branch_a”的范围，并且只是两个更改之间的文件相同，那么您可以从 master 说“branch_b”创建一个新分支，完成您的更改并提高 PR相同。在“branch_a”合并到 master 之后，您可以重新设置第二个分支“branch_b”以将更新的 master 代码库包含到 branch_b 中，（反之亦然，如果首先合并 branch_b）。如果没有事先确定合并的顺序，这将特别有用。

以下是 rebase 的步骤，这里的“feature_branch”是您要执行 rebase 的分支的名称：

git checkout master
git pull origin master
git checkout feature_branch
git rebase master

在这里，根据您的 feature_branch 中的提交次数，您可能会多次遇到一些冲突（如果有的话）。您可以手动解决冲突，并使用以下命令继续进行 rebase 的进一步处理：

git rebase --continue

在任何时候，如果您认为事情进展不顺利并且想取消 rebase 过程，请执行以下命令：

git rebase --abort

最后，当所有冲突都解决并且您收到成功合并的消息时，然后执行以下命令将更改推送到源：

git push --force origin feature_branch

有关变基过程的更多信息，请点击链接： https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase

【讨论】：