Git检测压缩合并分支

Question

我想知道是否有办法检测一个压缩的（在批准拉取请求后的远程）分支是否已合并到develop分支。通常，我使用

git branch --merged

然而，这似乎由于压缩而无法正常工作。

- Alexus

---

这就是我不喜欢压缩的（其中一个）原因，因为在内容被改变时，它也可能导致文件名的更改丢失。在我看来这是不好的习惯，不应该在正常团队工作流中被允许。 - Joe Phillips

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 的内容——即相关的 快照 ——与您的提交 K 的内容（快照）完全匹配，并且提交 IJK 的日志信息会告诉您他们是如何将 feature/yours 进行压缩合并的。因此，您现在知道可以安全地与他们重新同步并使用 IJK 代替删除 feature/yours。

但是，如果他们在某个其他提交 L 之后添加了 IJK，则他们现在具有：

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

在这种情况下，提交记录 IJK 的快照与您在获取后使用他们的 L 进行挑选或将其与他们的 upstream/somebranch 合并后合并的 feature/yours 结果相匹配。发现 这一点 更加困难。虽然对于许多情况可以自动化处理，但例如 GitHub 上没有按钮可以这样做。此外，如果他们不得不修改你的工作以使其适应他们的 IJK(虽然幸运的是大多数上游都不会这样做)，这样的自动化将失败，迫使您通过 rebase 或 merge 来自己调整您的 I-J-K 序列。:-) 在那种情况下，我们回到早期的情况，即您调整后的分支尖端提交与他们使用 squash-merge 操作所做的提交相匹配。

正如Joe Phillips在评论中所说，这种压缩的做法有些可疑。我不会说它永远不应该使用，但我会说，在大多数情况下，它应该是罕见的而不是常态。

- torek

---

当我在Web UI（企业版，但我想GitHub也一样）中看到git提交时：user1 authored and user2 committed 21 days ago这是否百分之百证明他们进行了压缩，并且来自用户1或用户2的提交已经丢失/重写？经过测试，我可以使用Octokit获取author.name和committer.name，所以想知道这是否是确定它来自存在压缩提交的分支的一种方法。@torek - JohnZaj

@JohnZaj： “X编写，Y提交”状态不能保证意味着“进行了压缩”-您可能会得到相同的结果，用于“变基，然后合并”操作，以及其他在这些Web界面上不会发生但可以通过命令行发生的情况-但它是一个相当强的指标。当提交中的作者行与提交者行不同时，会出现特定的状态。 - torek