我如何在 git 中知道一个分支是否已经重新定位到 master 上？答案

【问题标题】：How can I know in git if a branch has been already rebased onto master?我如何在 git 中知道一个分支是否已经重新定位到 master 上？
【发布时间】：2016-03-23 19:25:12
【问题描述】：

这与How can I know in git if a branch has been already merged into master? 非常相似，但它是关于检查重新定位的代码。在我目前正在处理的存储库中，似乎一些功能分支在它们的更改被重新定位到 master 之后已经搁浅了。在我删除分支之前检查这是否已完成的最佳方法是什么？

关于该分支的大多数建议都建议使用分支上最后一次更改的 SHA id 键来检查它是否存在于 master 中。我可以看到这是确保合并的最佳方法，但是当您重新设置此 SHA 时，此 SHA 已更改。

我也将发布一个答案，但我想知道人们是否认为有更好的选择。

【问题讨论】：

How can I know in git if a branch has been already merged into master?的可能重复
@dan 我不一定认为变基和合并是一样的。
不，变基会更改变更集的 SHA 密钥，因此该问题中的大多数答案都不适用于这个问题。变基的一种用途是重写变更集的历史，这使得在某些情况下很难或不可能弄清楚发生了什么。这就是我要问的这个问题。此外，rebase 似乎在 git 中得到了广泛使用，因此除了我自己之外的其他人找到具有被 rebase 到其他分支的废弃分支的存储库的可能性似乎很高。
@k0pernikus 当然它们是不一样的，但这里的真正意图是找到合并或未合并的内容，或者换句话说：什么已经是 master 的一部分。不属于 master 的部分将是未合并的分支。
git cherry，更多详情请参见我的回答stackoverflow.com/questions/16304574/…

标签： git branching-and-merging git-rebase

【解决方案1】：

在变基忠实于原始提交消息的情况下，@TafT 的回答会很好。此外，使用

git log --oneline --cherry master...some-branch

将在每次提交时显示=，从某个分支复制到主分支完全相同。

如果发生挤压等，提交消息会更改，或者如果您的变基发生冲突，则任何解决方案都不会起作用。在这种情况下，我建议如下（结帐到分离的 HEAD，这样我们就不会意外推送此合并）：

git checkout master~0
git merge some-branch

除非你的代码发生了巨大的变化，如果合并没有改变，那么分支已经被重新设置。否则，显然没有。

【讨论】：

@AndrewC 对该问题的评论解释说，某些樱桃命令使用了“补丁 ID”。这将使您的建议比我最初意识到的更合适，因为它不是基于执行变基时更改的“提交 ID”。

【解决方案2】：

在主分支日志中搜索功能分支的最后一条提交消息效果很好。

在主分支上做：

 git log -i --grep="<summary>"

其中是您的功能分支中最后一次提交的评论片段。这将为您提供主分支副本的提交 SHA、提交的作者和日期；最后两个由变基保留。如果您的作者、日期和评论相似，那么您可以确信更改已重新基于您正在检查的日志的分支。

如果使用 rebase 将所有功能分支提交压缩到 master 上的单个提交中，这将不起作用。

此方法可能存在其他问题，请将它们发布在 cmets 中或在可能的情况下提出更好的答案。

【讨论】：

【解决方案3】：

您还可以将功能分支重新定位到主分支。如果它已经被 rebase，那么特性分支在 rebase 之后将不会在 master 前面有任何提交，而是指向与 master 相同的提交。如果功能分支有 master 作为上游（git branch --set-upstream-to=master），那么您可以使用git branch -d feature-branch 安全地删除分支，git 将确保没有悬空提交。

【讨论】：