在工作中，我们有一个基于 git flow 的 git 工作流。我们有 3 个主要分支：dev、release 和 master
Dev 是我们目前正在做的事情，master 是我们在生产中所拥有的，而 release 是我们进行发布并进行最后一次错误修复的时候。当发布准备好时，发布分支被合并到 master 并推送到生产中。
在 master 中制作的任何修补程序也被推送到 dev （和发布分支（如果当前正在运行））
现在的问题是我们如何确保发布分支中的代码在合并后实际上是 master 中的代码？换句话说，release 和 master 之间应该没有差异（合并后）。
当从发布分支合并到 master 时，我们也不想处理冲突，所以任何一个都应该自动处理。
为了避免在合并到 master 时发生冲突，您可以使用 `git merge --ours' 忽略 master 中可能与发布更改发生冲突的任何更改，但是当您有多个开发流时，这可能会出现问题。例如，如果您有修复生产（主）代码的支持问题，或者如果您有多个发布分支。
与分支合作时，合并冲突是一揽子交易；它们会发生，只需调整您的工作流程以单独处理它们，以尽量减少任何不利影响。
为了说明这一点，请考虑这样一个场景：生产中存在已修复错误的现有版本，以及准备将发布分支移动到生产（合并到主）的发布分支。它看起来像这样：
master -A---------E------G
\ \ / /
bug-fix \ C-D /
\ /
release B--*--*--F
在此，B & C 是从 A 分支出来的，E 是提交 D 在bug-fix到master的合并提交，G 是提交 F 在release到master的合并提交。
如果在bug-fix和release中更改了相同的文件，则在 G 中可能会出现合并冲突。如果git merge --ours已在 G 处使用，则在 E 处所做的更改可能会丢失。
可以通过分支 master 并将 release 合并到其中来处理合并，然后将这个一次性分支重新定位到 master 上。只有在流程受到良好控制的情况下才应该这样做，例如指定一个人将所有合并到 master 中。
此时，G 将与 F 不完全相同，它还将包括在 E 的错误修复提交中引入的更改。
也可以将bug-fix合并到release和master中，这将使 F 和 G 再次相同。但是，有一种最佳做法是永远不要合并。这意味着，按照图中的顺序排列的分支（在顶部更稳定），合并应该始终从较低的分支到较高的分支。这有两个主要好处，第一个是稳定的代码不会合并到不太稳定的代码中，并且分支保持纯粹，因为它们只包含与它们引入的特性相关的更改。例如，如果 D 被合并到发布中，则需要与发布一起测试然后 release 包含它正在引入的功能的更改集和错误修复的更改集。
为了防止这成为问题，我总是检查更稳定的分支，将不太稳定的分支合并到其中并从那里开始。
另外，请注意，--ours这是签出的分支，是--theirs正在合并的另一个分支。当您更改合并的方向时，它们所指的更改将被交换。
release 和 master 合并后不可能不同。两个分支都指向同一个提交，合并提交将分支捆绑在一起。因此它们是完全相同的。
如果你想确保发布分支的内容成为主分支的内容，你想使用ours合并策略。这忽略了主分支中的变化，只是很好地取代了主分支的旧历史。所以你会做
git checkout release
git pull --strategy=ours . master
您想要的是“我们的”合并策略。正如git merge 手册页中所指出的，它将始终使用合并的“我们”一侧，而忽略“他们”一侧的所有内容。它明确提到，当一方完全取代另一方时使用它。
编辑：请注意，“递归”策略有一个“我们的”策略和一个“我们的”选项。您想要前者，即策略而不是策略选项。