Question

我想知道是否存在一种方法来检测压缩的分支（在批准拉取请求后在远程上）是否合并到development中。通常，我使用

git branch --merged

但是，由于挤压，这似乎不起作用。

Answer 1

简短的回答是，尚无一般而可靠的方法来说明。

在许多特定情况下，通过将添加到上游存储库的新提交的 contents 与您建议的合并的 contents 进行比较，很容易看出来。也就是说，在您的存储库中和/或在GitHub上您控制的克隆上，如果您和他们通过GitHub进行了合并，则您拥有：

...--G--H   <-- origin/somebranch, upstream/somebranch
         \
          I--J--K   <-- feature/yours

他们使用“压缩并合并”将您的三个提交I，J和K合并为一个大的IJK提交，他们在提交H之后添加的内容，因此其存储库现在显示为：

...--G--H--IJK   <-- somebranch

提交IJK的内容（如关联的快照）与提交K的内容（快照）和提交{ {1}}可以告诉您它们是壁球合并的IJK。因此，您现在知道与它们重新同步并使用feature/yours删除feature/yours是安全的。

但是，如果他们在其他一些提交IJK之后添加了IJK，则他们现在有：

在这种情况下，提交...--G--H--L--IJK <-- somebranch的快照与您在选择IJK的过程中选择樱桃，或者将L与feature/yours合并后获得的快照匹配。发现 this 更加困难。在很多情况下，它可以自动化，但是例如，在GitHub上没有clicky按钮可以做到这一点。此外，如果他们必须修改以完成自己的工作upstream/somebranch，会失败，尽管幸运的是（？）对您来说大多数上游公司都不会这样做从而迫使您通过重新定基础或合并来自己调整IJK序列。 :-)在这种情况下，我们回到了较早的情况，在该情况下，适应的分支提示提交与他们通过壁球合并操作所做的匹配。

与Joe Phillips says in a comment一样，像这样压榨的整个过程有些可疑。我不会说不应该使用它，但在大多数情况下应该很少使用它而不是规范。

Git检测壁球和合并的分支

1 个答案: