我在工作时创建了一个分支 (branch1)，然后创建了一个 pr (pr1)，然后我继续开发基于该分支 1 中的代码的功能。我从我的分支 (branch1) 创建了一个分支 (branch2)。然后我创建一个基于 pr1 的 pr(pr2)。也许有一些关于 pr1 的反馈。所以我在 branch1 上创建了一个新提交并将其推送到 pr1。然后我将 branch1 合并到 branch2 并更新 pr2.
这似乎是一种完全自然的工作方式，事实上我看不出任何其他合理的工作方式，除非将所有内容都放在一个分支中并将大量 pr 交给我的队友进行审查。
问题是远程设置为将您的 pr 合并到 main 中。所以我将 pr1 合并到 main 中。然后 main 有 1 个新提交，branch2 有 x 个基本孤立的提交。当我尝试将 main 合并到 branch2 时，我花了接下来的一个小时来解决冲突，希望我不会撤消大量工作。
鉴于我们正在使用壁球合并这一顽固的事实，我只能看到几个“解决方案”。
merge p4, into pr3 into pr2 into pr1, then squash merge pr1 into main.这很糟糕，因为你很容易忘记新提交合并到哪里，如果它们已经被审查过，那可能真的是一团糟
准确地找出哪些提交在 branch2 而不是在 branch1（记住 branch1 仍然有很多提交，只有 main 有挤压）。然后，我想创建一个新分支。说 branch2.1 脱离 main 并仅将那些提交到新分支的变基。这很糟糕，因为 a) 我什至还没有弄清楚该怎么做 b) 然后我会在 branch2 上丢失 pr2 的所有上下文，因为它现在是 branch2.1 和 c) 因为即使有可能我怀疑它会是一个很容易搞砸的多步骤过程。
我认为要求开发人员等待 PR 完全审查和合并后再做更多工作是不合理的。我还认为，很多人，尤其是做出像挤压合并这样的决定的高层，因为这让他们很容易看到存储库中发生了什么。
到目前为止，我已经搜索（在解决冲突之间）好几天了，还没有找到任何系统，甚至没有找到关于如何克服这种情况的讨论。我的第一个问题是，是否有已知的方法可以做到这一点。我的第二个问题是，如果没有，我如何着手制作一系列命令，这些命令将可靠地为我提供正确的提交，以及如何将它们置于来自远程的压缩之上。
谢谢。
看来是你在合并这些PR。这意味着 你可以在你这边模拟这种“挤压”，并以这种方式跟上 与遥控器正在做的恶作剧。 （我假设它是 必须进行实际合并的遥控器，否则你不会在 这种困境。）
当你要合并位于
xyzgit switch zgit rebase --interactive --update-refs <main branch>--update-refsxxz--update-refs（它也可以重新设置堆栈底部 w.r.t. 更新 堆栈中的所有分支。我不确定。）
--update-refszxzRebase
z现在您的分支堆栈应该已正确更新。