Git检测壁球和合并的分支

Question

我想知道是否有办法检测被压扁的（批准拉取请求后在远程）分支是否合并到开发中。通常，我使用

git branch --merged

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

Answer 1

简短的回答是没有通用但可靠的方法来判断。

在许多特殊情况下，很容易通过比较来告诉内容的新的提交加入到上游资源库的内容，你提出的合并。也就是说，在你的存储库中——和/或你在 GitHub 上控制的克隆，如果你和他们通过 GitHub 进行合并——你有：

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

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

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

提交的内容（如相关联的快照IJK）与您的 commit 的内容（快照）完全匹配K，并且commit的日志消息IJK告诉您它们已压缩合并feature/yours。因此，您现在知道与它们重新同步并feature/yours使用delete 是安全的IJK。

但是，如果他们IJK在其他一些 commit 之后添加L，他们现在有：

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

在这种情况下，快照提交IJK比赛，如果你精挑细选的，你会得到L，或合并你feature/yours与他们的upstream/somebranch后取。发现这一点比较困难。它可以在许多情况下自动化，但例如，GitHub 上没有可点击的按钮来执行此操作。此外，如果他们不得不修改您的工作以使其成为他们的工作，那么这种自动化将失败——IJK尽管幸运的是（？）对您来说，大多数上游不会这样做，迫使您I-J-K自己通过重新定位或合并来调整您的序列。:-) 在这种情况下，我们又回到了之前的情况，在这种情况下，您调整后的分支提示提交与他们使用压缩合并操作所做的匹配。

正如乔·菲利普斯在评论中所说，像这样压球的整个做法有些可疑。我不会说永远不应该使用它，但我会说在大多数情况下它应该很少见而不是常态。