【发布时间】:2013-04-24 15:35:35
【问题描述】:
在之前的问题中,有人提供了查找包含 EXACT 提交的分支的答案:
How to list branches that contain a given commit
接受的答案强调这仅适用于 EXACT 提交 id,不适用于相同的提交。进一步指出,Git Cherry 可以用来解决这个问题。
Git cherry 似乎是为反向而准备的;查找未推送到上游的提交。如果我不知道哪个分支创建了它以及上游是什么,这将毫无用处。所以我看不出它将如何帮助解决这个问题。
有人可以解释/提供一个示例,说明如何使用 git cherry 查找包含特定提交的“等效”的所有分支吗?
【问题讨论】:
-
我建议编写一个使用
git rev-list和git patch-id的脚本来确定这一点。您可能还需要解析git cherry-pick在提交消息中留下的注释,因为补丁 ID(也是git cherry的基础)并不完美,如果您解决了任何冲突,它将中断。 -
无意 +1 评论:我不知道你说了什么或者它对我有什么帮助。我用它们来生成什么列表?让我们假设有人解决了冲突,并且我的队友不够聪明,无法使用cherrypick -x,因为我不得不向他们指出。
-
好吧,那你就完蛋了。如果你想确切地知道哪些分支包含哪些提交,只使用合并而不是挑选。您可以假设具有相同提交消息的提交可能是相同的,并对它们的差异做一些时髦的启发式方法来验证该假设。但是这个过程很容易出错,你必须自己编写代码。
-
听起来其他页面的海报是错误的。这主要是出于好奇,并验证我决定在请求合并之前强制队友变基,以便我们所有的合并都是 FF,因此没有樱桃选择和冲突等。我感谢你的帖子!现在我的意思是两个+1 :-)
-
这是 OT,但我认为仍然很重要:这似乎是对 rebase 的常见误解。如果您希望分支易于合并,只需让所有者将 master 合并到其中即可。当你变基时,你不仅会以线性历史告终,还会以谎言告终。中间提交甚至可能不再起作用,因为在变基期间没有人测试。这可能会让你的历史变得毫无用处。另一方面,真正的合并会告诉您哪些部分是独立开发的,这也很有用。 Git 不是 svn,git 根本不需要线性。
标签: git version-control