我正在尝试清理大量主题分支，主要是因为github中master的分支概述不再在非活动主题分支中显示虚假的“n ahead”指示符，因为存在相同的更改
如果没有这些虚假指标，这个概述页面将提供一个很好的方式来一目了然地看到来自旧主题分支的任何提交是否被无意中遗漏并且没有合并回master。
在下图中，Y是分支topic中的提交，后来作为master应用于Y'（因此它们具有不同的sha1哈希，但是相同的修补程序IDS）。
A --- B --- C --- Y' --- E <-- master
\
X --- Y <-- topic
git cherry master topic适当地报告：
- Y
但是如果我尝试通过从git merge topic发出master来清除此问题，我会发现合并冲突，因为E中的更改master已经改变了上下文补丁应用了哪些。
有没有办法告诉master“嘿，你确实已经拥有Y，所以你可以停止报告你没有。”？ （能够以自动/编程方式应用的方式执行此操作是关键。）
答案 0 :(得分：1)
您可以通过将--cherry-pick选项传递给git log来查看分支之间修订的有效差异。
我最喜欢的咒语运行：
git log --left-right --graph --cherry-pick --oneline branch1...branch2
（我将别名设为git lr）。
来自the man page：
--cherry-pick当提交集受限于对称差异时，省略任何在“另一方”引入相同更改的提交。
例如，如果您有两个分支A和B，通常只在其中一侧列出所有提交的方法是使用
--left-right（请参阅下面{{1}的说明中的示例} 选项）。然而，它显示了从另一个分支中挑选出来的提交（例如，“b上的第3个”可以从分支A中挑选出来）。 使用此选项，此类提交对将从输出中排除。--left-right与
--cherry-mark类似（请参阅以上 上面的），但使用--cherry-pick标记等效提交而不是省略它们，并使用{{1标记不等价的提交}}。
为了永久让git停止担心实际上被挑选出来的提交，你总是可以合并另一个分支。合并提交将被标记为先前提交和合并修订树的提示的子修订。
这告诉修订树遍历在此时停止遍历历史记录。这样做只有在合并来自“其他”分支的修订版本时才是安全的IFF你知道所有它的父已经合并（就你希望它们合并而言）。
还有一些way to use grafts。这真的意味着你将告诉git - 带外1 - 某个版本是另一个版本的子版本，而不必实际修改/合并它。
1，如带有一对sha1哈希的手写文件：）
关于这一点的好处是你没有 来重写历史以使其发挥作用。但是，如果您愿意，可以使用git filter-branch to make the grafts permanent。您不再需要 grafts 文件，但当然，您将回到必须重写历史记录（以及可能使已发布的修订ID无效）的缺点。
<子>
如果所有其他方法都失败了，有时您可能会遇到您经常想要合并的远程（主题）分支，但是您可能根本就不想采取这些分支。这些可能会一次又一次地导致相同的合并冲突。
在这种情况下，我只会指出git-rerere (Reuse recorded resolution of conflicted merges)这可以使生活变得更加容易，虽然更复杂
答案 1 :(得分：0)
这是一个奇怪的回避，不想rebase历史，因为这是一个公共回购，但考虑使用revert，merge和一个计数器{{1 }}
在revert上，单独还原E和Y'以将master恢复到其在C的状态（提交消息表明您正在引入一个被遗忘的主题分支，而不是删除更改）：
master记下E的还原提交的sha1，或git revert E
git revert Y'
它。
现在，您可以将git tag revert_E sha1合并到topic：
master此时主题已正确合并，并且git merge topic
返回其状态直到Y / Y'，您现在可以master还原提交E以恢复它：
revert将会干净地应用，因为git revert revert_E
处于与最初提交E时相同的状态（该状态的历史记录刚刚更改）。感觉有点杂技，但会解决你的问题。我想不出更清洁的东西。
答案 2 :(得分：0)
我不确定为什么我之前没有想到这一点，但只要相同的更改列表是master和topic之间的唯一区别，git merge -s ours topic来自{{ 1}}将轻松解决问题。合并显然会在没有冲突的情况下适用，并且合并的存在将消除虚假的未合并指标。
我的github分支概述页面现在没有误导“n ahead”指示符，因此真正的未合并提交将明显突出。