git合并而不合并

Question

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

我正在关注http://nvie.com/posts/a-successful-git-branching-model/,它说将发布分支合并回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合并,但将使用分支中的所有(且仅)文件dev.是否真正获得你什么取决于你如何使用这些:做这样的合并的一点是,如果有在以后的修复rel7,可纳入dev 不改变,¹你可以提交它rel7,再后来,git merge rel7到dev到拿起相同的修复程序dev.

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

这里的想法是你首先在发布分支上进行修复,然后git merge在开发线上进行相同的修复.使这种"虚拟"与ours策略合并只是简单地设置,以便下一次合并不会尝试引入"fix1b".

使用链接页面上描述的方法,您将首先在发布分支(或发布分支上的分支上)编写"fix1b",然后对其进行测试和发布.然后你会做一个git merge把它带进来dev,如果那个合并需要改变,你可能已经将更改作为合并的一部分(有些人真的不喜欢这个方法)或者之后作为单独的修复提交(我不喜欢这个一个人,它经常让合并提交本身破坏或失败测试).