正确合并链式特征分支

Question

情况

我正在开发跨多个分支的功能。 我有一个分支

issue-1

正在等待与挤压提交合并。 我从中检查了新分支，

issue-2

来处理它。 （我需要从

issue-1

进行更改才能在此基础上进行。） 一段时间后，

issue-1

合并为

main

（压缩提交）

A--B--C---------K (main)
       \       /
        E--F--G (issue-1)
               \
                H--I--J (issue-2)
              

能够合并

issue-2

我必须这样做

git rebase --onto K G issue-2

这样下次合并就会顺利

A--B--C---------K (main)
       \       / \
        E--F--G   H'--I'--J' (issue-2)
       (issue-1)
              

问题

当

issue-1

接受的合并请求也提供删除源分支时。

issue-2

的历史记录包含来自

issue-1

的提交，这些提交已经合并。如何找到

rebase --onto

的正确提交？我能够从合并中找到 K 。但是我在哪里可以找到不存在分支的最后一次提交，或者最后一次合并到主干中的提交是什么？ 我考虑过将其放入合并提交消息中，但我并不总是负责合并。 第一次合并（和源删除）后，它看起来像这样

A--B--C---------K (main)
       \       
        E--F--G--H--I--J (issue-2)              

现在我需要

git rebase --onto K ? issue-2

或者有更好的方法吗？

Answer 1

我有一个分支

issue-1

正在等待与squash提交合并。

由于您已经在本地拥有分支，而不是：

git rebase --onto K G issue-2

您可以只使用分支名称：

git rebase --onto K issue-1 issue-2

当问题 1 接受的合并请求也提供删除源分支时。

没关系，但它不会删除您本地的

issue-1

副本，因此您仍然会拥有它。使用

issue-2

的本地副本对

issue-1

进行变基后，最好删除

issue-1

的本地副本，因为您不再需要它。

如果由于某种原因您在重新设置基础之前删除了

issue-1

，您可以使用

git reflog

来回顾创建分支

issue-2

时您所在的提交。

此外，正如评论中提到的，您的 SCM Git 工具也可能会向您显示分支的历史记录。既然你提到了“合并请求”，那就意味着 GitLab，并且每个合并请求的历史记录在 MR 完成后仍然可用。