这与How can I know in git if a branch has been already merged into master?非常相似，但与检查重新设定的代码有关。在我目前正在处理的存储库中，似乎有一些功能分支在他们的更改被重新定位到master之后被搁置了。在删除分支之前，检查这是否已完成的最佳方法是什么？
该分支上的大多数建议建议使用分支上最后一次更改的SHA id键来检查它在master中的存在。我可以看到这是确保合并的最佳方法，但是当你重新设置时，这个SHA会被更改。
我有一个答案，我也会发布，但我想知道人们是否认为有更好的选择。
答案 0 :(得分：2)
如果rebase忠实于原始提交消息，@ TafT的答案将会很好。另外，使用
git log --oneline --cherry master...some-branch
将显示=每个从某个分支到主分支完全相同的提交。
如果正在进行压缩等，则会更改提交消息，或者如果您的变基有冲突，则解决方案都不起作用。在这种情况下，我建议如下（Checkout分离HEAD，以便我们不会意外地推动此合并）：
git checkout master~0
git merge some-branch
除非您的代码发生了巨大变化，否则如果合并没有变化，那么分支已经重新定位。否则，它显然没有。
答案 1 :(得分：1)
通过主分支日志中的功能分支的最后一次提交消息进行搜索非常有效。
在主分支上执行：
git log -i --grep="<summary>"
其中 是功能分支中最后一次提交的注释的一部分。这将为您提供主分支副本的提交SHA，提交的作者和日期;最后两个由rebase保留。如果您的作者，日期和评论相似，那么您可以确信更改已重新定位到您正在检查的日志的分支上。
如果使用rebase将所有功能分支提交压缩到master上的单个提交中，则无效。
此方法可能存在其他问题，请在评论中发布或尽可能提出更好的答案。
答案 2 :(得分：0)
您还可以将功能分支重新设置到主分支上。如果它已经被rebase，那么rebase 之后，特性分支在master 之前不会再有任何提交，而是指向与master 相同的提交。如果功能分支将 master 作为上游 (git branch --set-upstream-to=master)，那么您可以使用 git branch -d feature-branch 安全地删除该分支，并且 git 将确保没有悬空提交。