git - 将版本 merge 到主版本中，没有产生差异

Question

在工作中，我们有一个基于 git flow 的 git 工作流程。我们有 3 个主要分支:dev、release 和 master

Dev 是我们目前正在做的事情，master 是我们在生产中拥有的东西，release 是当我们进行发布并进行最后的错误修复时。发布准备就绪后，发布分支将 merge 到主分支并推送到生产环境中。

master 中的任何修补程序也会被推送到 dev(和发布分支(如果当前正在运行))

现在的问题是我们如何保证 merge 后release分支中的代码实际上是master中的代码？换句话说，release 和 master 之间应该没有区别( merge 后)。

当从发布分支 merge 到 master 时，我们也不想处理冲突，所以任何冲突都应该自动处理。

Answer 1

为了避免在 merge 到 master 时发生冲突，您可以使用 `git merge --ours'，它会忽略 master 中的任何更改，这些更改会与 release 中的更改发生冲突，但是当您有多个开发流时，这可能会出现问题.例如，如果您有修复生产(master)代码的支持问题，或者如果您有多个发布分支。

merge 冲突是处理分支时的一揽子交易；它们会发生，只需调整您的工作流程以隔离处理它们，以尽量减少任何不利影响。

为了说明这一点，请考虑这样一个场景，在该场景中，生产中有一个已修复错误的现有版本，并且有一个发布分支已准备好移至生产( merge 到主分支)。它看起来像这样:

master  -A---------E------G
          \   \   /      /
bug-fix    \   C-D      /
            \          /
release      B--*--*--F

其中，B & C 是从 A 分支出来的，E 是提交 D 在 bug-fix 到 ma​​ster 上的 merge 提交，G 是提交的 merge 提交F 在发布到ma​​ster。

如果在 bug-fix 和 release 中更改了相同的文件，则在 G 可能会出现 merge 冲突。如果在 G 处使用了 git merge --ours，则在 E 处所做的更改可能会丢失。

可以通过分支 master 并将 release merge 到其中来处理 merge ，然后将这个一次性分支 rebase 回 master。只有在流程得到很好控制的情况下才应该这样做，例如指定一个人将所有 merge merge 到 master 中。

在这一点上，G 不会完全像 F，它还将包括在 E 的错误修复提交中引入的更改。

也可以将 bug-fix merge 到 release 以及 ma​​ster 中，这将使 F 和 G 再次相同。但是，有一种最佳做法是永远不要向下 merge 。这意味着，随着图中分支的顺序排列(顶部更稳定)， merge 应该总是从较低的分支到较高的分支。这有两个主要好处，首先是稳定的代码不会 merge 到不太稳定的代码中，分支保持纯粹，因为它们只包含与它们引入的功能相关的更改。例如，如果 D 被 merge 到 release 中，则需要与 release 一起进行测试，然后 release 包含它引入的功能的变更集和变更-错误修复集。

为了防止这成为一个问题，我总是检查更稳定的分支，将不太稳定的分支 merge 到其中，然后从那里开始。

另外，请注意 --ours 是被 check out 的分支，--theirs 是被 merge 的另一个分支。当你改变方向时 merge ，他们所指的更改被交换。