我的工作流程需要一些帮助。我通常创建一个分支并在 github 上打开拉取请求（标准程序）。但是，有时我想创建另一个 PR，该 PR 依赖于之前仍处于打开状态的 PR。我希望在第一个 PR 仍处于开放状态时对第二个 PR 进行评论。
为此，我首先创建另一个分支（在之前的分支之外）并打开一个 PR，请求对第一个分支进行更改。同时，如果我对第一个分支进行了更改（解决第一个 PR 的评论），我会将它们提交到第一个分支，然后将它们重新设置到第二个分支。然后，我将第一个分支和第二个分支强制推送到它们的遥控器。
然而，问题是第二个 PR 有时会显示与第一个分支相比的变化。这是一个线性历史，我认为 github 很混乱。我尝试了这个奇怪的事情，我将第二个 PR 中的分支更改为其他共同祖先分支，然后将其更改回第一个分支，突然间，第一个分支中不应该出现的更改消失了。
有没有办法防止这个问题的发生？我从来不希望第一个 PR 的更改出现在第二个 PR 中（作为提交）。我只是希望第二个 PR 看起来像是正在向第一个 PR 提交更改。
合并第一个 PR 后，我通常会进入第二个分支并rebase --onto our_main_branch更新 github 中的第二个 PR 以请求将更改合并到our_main_branch. 我也欢迎对更好的工作流程提出任何意见。
mat*_*att 10
事实上，GitHub 很好地应对了这种情况。您只需确保第二个 PR 不会在第一个 PR 之前被接受。
\n假设您正在研究main. 因此，main您创建一个分支feature1并将其推送并请求 PR合并到main. 然后你想继续工作，所以你feature2 从 中feature1创建一个分支，当你完成时，有两种可能性：
与此同时，feature1PR获得批准并合并。在这种情况下，拉取main并重新建立feature2基础main，然后推送feature2并请求 PR合并到main。
好吧，现在让我们假设仍在feature1等待批准。听起来很糟糕，是吗？但没问题！无论如何，只要推动feature2，并要求将 PR合并到feature1. 它看起来就是您想要的样子！\xe2\x80\x94 这是精彩的部分。如果feature1现在被接受并合并，PR 将自动更改为合并到main，这正是您一直想要的。而且它看起来仍然完全是您想要的样子。基本上 GitHub 已经在幕后为你完成了 rebase。