Question

我有一个问题，我在dev和本月的发布分支上分别做了同样的bug修复，但由于架构差异，修复程序在两个分支上的不同文件中。

我正在关注http://nvie.com/posts/a-successful-git-branching-model/，它说将发布分支合并到dev中，但是由于该修复已经在dev中应用了，是否有一种简单的方法可以“合并”但只保留dev中的内容？

dev branch:      dev - changes - fix1a - moreChanges -?- justKeepDev
                   \                                     /?/
release branch:     release14.01 - fix1b ----------------

Answer 1

有ours合并策略（不要与ours合并策略的recursive参数混淆：

$ git checkout dev
$ git merge -s ours rel7

这将在分支dev中进行合并提交，以便dev似乎已合并rel7，但将使用分支{{1}中的所有（且仅限）文件}}。这真的让你获得了什么取决于你如何使用这些：进行这种合并的重点是，如果dev上的后续修复可以合并到rel7 而没有任何更改< / em>，¹您可以先将dev提交给rel7，然后再将git merge rel7提交到dev，以便在dev中提取相同的修补程序

¹换句话说，作为单独的“fix1b”然后“fix1a”提交进入的修复不符合条件。您无法简单地合并fix1b更改，因为它进入了不同的文件/函数/无论如何。首先在rel7中解决问题，然后将rel7合并到dev中没有任何好处。（通常很难预先知道这是否属实，所以你可以按照下面的描述进行尝试，然后发现无利害案例......之后，你可以选择你的毒药“如何要做到这一点“对于这种情况没有单一的最佳答案。”

这里的想法是你首先在发布分支上进行修复，然后git merge同样修复开发行。使用ours策略进行“虚拟”合并只会设置一些内容，以便 next 合并不会尝试引入“fix1b”。

使用链接页面上描述的方法，您将首先在发布分支（或发布分支上的分支）上编码“fix1b”，然后对其进行测试和发布。然后你会做git merge将它带入dev，如果合并需要更改，你可能已将更改作为合并的一部分（有些人真的不喜欢这种方法）或作为之后单独的修复提交（我自己不喜欢这个，它经常使合并提交本身损坏或测试失败）。

Answer 2

如果我理解正确，ours合并策略应该做你想要的。来自文档：

ours
    This resolves any number of heads, but the resulting tree of
    the merge is always that of the current branch head,
    effectively ignoring all changes from all other branches. It
    is meant to be used to supersede old development history of
    side branches. Note that this is different from the -Xours
    option to the recursive merge strategy.

要使用此功能，请执行

git checkout dev
git merge -s ours release14.01

Answer 3

执行此操作的一种方法是还原fix1a，然后将您的发布分支直接合并回您的开发分支。这将有效地撤消fix1a引入的所有更改，以便当您从发布分支合并相同的修补程序时，修复程序将有希望返回到开发分支。如果您目前位于moreChanges分支机构的dev和fix1b分支机构的release14.01，那么类似于：

git checkout dev
git revert (commit hash of fix1a)
git merge release14.01

如果您需要帮助可视化还原将会执行的操作，我认为找到here的图表会很有用。

git合并而不合并

3 个答案: