在主银行被挤压合并后,从主银行重建支行

我继续在本地开发同一分支

那是你的失误。你永远不应该那样做。具体来说,一旦你完成了 压扁了 合并来自分支的请求,您应该放弃(删除)该分支。原因是压缩的合并不是合并,因此您“合并”的提交都是自合并库(您创建的点)以来的新提交 devel ); 他们是 不 与你分支中仍然存在的六个commit相同。因此,它们可能会与你在分支机构继续工作时所做的事情相冲突,正如你现在所发现的那样。

正确的做法是放弃这个分支。Fetch,并在origin/main的末尾创建一个新的分支(即main分支) 现在 站立)。在以下基础上实施新的更改 那个 。现在,您将拥有可以干净合并的东西。

如果可能的话,避免挤压合并。正如你所发现的,它主要会引起头痛。但并没有失去一切。

假设您从以下历史图开始,2个提交只能从以下位置访问 main 4个承诺 devel 树枝

A-B-C-D             < main
   \
    E-F-G-H         < devel

接下来,您创建一个合并请求并压缩合并。这会给您一个新的提交,我称之为 S (“壁球”的缩写)。它包含提交后的所有更改 E , F , G 和 H .

A-B-C-D-S           < main
   \
    E-F-G-H         < devel

然后,你继续在你的分支上工作,并添加更多的提交:

A-B-C-D-S           < main
   \
    E-F-G-H-I-J-K   < devel

您无法再次合并它,因为更改已经部分应用于main。尝试简单的重基也会失败,因为 S 包含以下更改 E 和 F 和 G 和 H 所以 E 无法再次申请,就像申请一样 E 在上面 H .

但你可以通过告诉Git旧的上游是什么来帮助它:

git rebase --onto main H devel

此命令将接受提交范围 H..devel (即。 I , J , K )并将其应用于 主要的 这应该会减少冲突,并避免重新应用上游已经存在的补丁。重设基点后的历史:

A-B-C-D-S           < main
   \     \
    \     I'-J'-K'  < devel
     \
      E-F-G-H-I-J-K