5

我正在尝试清理大量主题分支，主要是为了使mastergithub 中的分支概述不再在非活动主题分支中显示虚假的“n提前”指示器，因为存在相同的更改。

如果没有这些虚假指标，此概览页面将提供一种很好的方式，让您可以一目了然地查看旧主题分支中的任何提交是否被无意中遗漏并且没有合并回master.

在下图中，Y是分支topic中的提交，后来应用于masteras Y'（因此它们具有不同的 sha1 哈希，但补丁 ID 相同）。

A --- B --- C --- Y' --- E    <-- master
       \ 
        X --- Y               <-- topic

git cherry master topic适当地报告：

- Y

git merge topic但是，如果我尝试通过发出from来清理它master，我会遇到合并冲突，因为更改E已经master改变了应用补丁的上下文。

有没有办法告诉master“嘿，你真的已经Y有了，所以你可以停止报告你没有。”？（能够以可以自动/以编程方式应用的方式做到这一点是关键。）

4

3 回答 3

1

您可以通过将 --cherry-pick 选项传递给 git log 来查看分支之间修订的有效差异。

我最喜欢的咒语运行：

git log --left-right --graph --cherry-pick --oneline branch1...branch2

（我有别名）git lr。

从手册页：

--cherry-pick

当提交集受到对称差异的限制时，忽略任何引入与“另一侧”上的另一个提交相同的更改的提交。

例如，如果您有两个分支，A 和 B，则仅列出其中一侧的所有提交的常用方法是 with --left-right（请参阅下面选项描述中的示例--left-right）。然而，它显示了从另一个分支中挑选出来的提交（例如，“b 上的第 3 个”可能是从分支 A 中挑选出来的）。使用此选项，此类提交对将从输出中排除。

--cherry-mark

类似--cherry-pick（见下文） ，但=用+.

永久解决方案#1

为了永久地让 git 不再担心那些实际上是精心挑选的提交，你可以随时合并其他的 branh。合并提交将被标记为先前提交和合并修订树顶端的子修订。

这告诉修订树遍历在该点停止遍历历史。只有在合并来自“其他”分支的修订版时，这样做才是安全的，前提是您**知道它的所有父级都已合并（只要您希望它们合并）。

永久解决方案#2

还有一些方法可以使用移植物。这实际上意味着您将告诉 git - out of band 1 - 某个修订版是另一个修订版的子版本，而不必实际重新定位/合并它。

1如，带有 sha1 散列对的手写文件 :)

积极的一面是你不必重写历史来让它工作。但是，如果您愿意，可以使用git filter-branch使移植物永久化。那时您不再需要移植文件，但是当然，您将不得不重写历史记录（并且可能使已发布的修订 ID 无效）。

松散的结局？

如果所有其他方法都失败了，有时您可能会遇到您经常想要合并的远程（主题）分支，但有些差异是您根本不想接受的。这些可能会一遍又一遍地导致相同的合并冲突。

在那种情况下，我将只指出git-rerere（重用记录的冲突合并的解决方案），它可以使生活变得更加轻松，尽管更复杂

于 2011-07-09T19:34:49.340 回答
0

这是一个奇怪的回避，不想rebase历史，因为这是一个公共回购，但考虑一个解决方案revert，merge, 和 counter revert。

On master，分别恢复 E 和 Y' 以恢复master到其在 C 处的状态（提交消息说您正在引入一个被遗忘的主题分支，而不是删除更改）：

git revert E
git revert Y'

记下 E 或git tag revert_E sha1它的恢复提交的 sha1。

现在您将能够合并您的topic到master：

git merge topic

此时主题正确合并，并master返回到 Y/Y' 的状态，您现在revert可以恢复 E 的提交以恢复它：

git revert revert_E

这将完全适用，因为master它与您最初提交 E 时的状态相同（该状态的历史刚刚改变）。感觉有点杂技，但会解决你的问题。我想不出任何更清洁的东西。

于 2011-07-09T15:34:41.140 回答
0

我不知道为什么我以前没有想到这一点，但只要相同的变更列表是 and 之间的唯一区别master，topicfromgit merge -s ours topic就master可以轻松解决问题。显然，合并将在没有冲突的情况下应用，并且合并的存在将消除虚假的未合并指示符。

我的 github 分支概览页面现在没有误导性的“n ahead”指示符，因此真正的未合并提交将清楚地显示出来。

于 2011-07-11T18:07:59.760 回答