我想知道是否有办法检测一个压缩的(在批准拉取请求后的远程)分支是否已合并到develop分支。通常,我使用
git branch --merged
然而,这似乎由于压缩而无法正常工作。
git branch --merged
然而,这似乎由于压缩而无法正常工作。
简单来说,目前还没有一种通用且可靠的方法可以确定。
在许多特定情况下,可以通过比较添加到上游仓库的新提交的内容与您提出的合并的内容来轻松判断。也就是说,在您的仓库和/或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 操作所做的提交相匹配。user1 authored and user2 committed 21 days ago
这是否百分之百证明他们进行了压缩,并且来自用户1或用户2的提交已经丢失/重写?经过测试,我可以使用Octokit获取author.name和committer.name,所以想知道这是否是确定它来自存在压缩提交的分支的一种方法。@torek - JohnZaj