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

Question

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

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

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

Answer 1

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

Answer 2

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

如果请求的另一个更改在功能“branch_a”的 scope 之外，并且两个更改之间只是一个文件相同，那么您可以从 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

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