【问题标题】:Cherry-pick a merge樱桃选择合并
【发布时间】:2010-09-18 23:12:20
【问题描述】:

假设分支 B 是分支 A 的一个主题分支,并且您希望在分支 C 中进行这些更改。当您选择分支 A 和分支 B 的合并提交到分支 C 时,这意味着什么?

例如,如果您使用 -m 标志来指定分支 A 的旧 HEAD 以樱桃选择合并到分支 C,这是否只是意味着“获取樱桃选择的提交树和旧 HEAD 之间的差异分支 A 并将其应用到分支 C?”

使用这种方法有什么问题吗? (例如,分支 C 是否看起来像是合并到分支 A 和 B?会应用更多更改而不是简单地从分支 B 提交吗?)

【问题讨论】:

    标签: git version-control


    【解决方案1】:

    我通常这样做的方式是使用git rebase:

    git rebase --onto C A B
    

    这会获取 A 和 B 之间的差异,并将这些差异应用到分支 C。作为奖励,rebase 将跳过 A 和 B 之间执行与分支 C 中已经存在的相同文本更改的任何提交。

    更新:对于您在 cmets 中提到的情况,请记住 Git 永远不会覆盖过去的历史记录。因此,即使在进行了上述变基之后,您也可以在 B 曾经在变基之前的提交处重新创建一个新的分支头。不幸的是,在早上的这个时候,我想不出一个简单的方法来做到这一点。对不起,我不能提供更多帮助,也许其他人会想出一个简单的方法!

    【讨论】:

    • 对不起,我遗漏了我希望分支 B 中的更改同时应用于 A 和 C。rebase 会导致 B 中的更改很容易与 C 合并,但现在 A 在C 所处的情况。我能做些什么来让 A 也发生这些变化?
    • 我也很抱歉在提出问题时选择了如此糟糕的分支名称:(
    猜你喜欢
    • 2016-05-04
    • 2017-02-26
    • 2018-07-23
    • 2012-01-11
    • 2013-01-07
    • 1970-01-01
    • 1970-01-01
    • 2012-04-17
    • 2018-08-14
    相关资源
    最近更新 更多