在工作中，我们有一个基于git流的git工作流。我们有3个主要分支：dev，release和master
Dev是我们目前正在开发的东西，master就是我们在生产和发布中所拥有的，当我们正在进行发布并进行最后的bug修复时。当发布准备就绪时，发布分支将合并到master中并推送到生产中。
在master中创建的任何修补程序也会被推送到dev（和发布分支（如果当前正在运行））
现在的问题是我们如何确保发布分支中的代码实际上是合并后的master中的代码？换句话说，release和master之间应该没有差异（合并之后）。
当从发布分支合并到master时，我们也不想处理冲突，因此任何一个都应该自动处理。
答案 0 :(得分：5)
为了避免在合并到master时出现冲突，可以使用`git merge --ours'来忽略master中与release中的更改冲突的任何更改，但是当你有多个开发流时，这可能会出现问题。例如，如果您有支持问题，修复生产中的代码（主）或者您有多个发布分支。
合并冲突是与分支机构合作时的一揽子协议;它们会发生，只需调整您的工作流程就可以单独处理它们，以最大限度地减少任何不利影响。
为了说明这一点，请考虑以下情况：生产中存在已修复错误的现有版本，并且已准备好将发布分支移至生产（合并为主数据库）。它看起来像这样：
master -A---------E------G
\ \ / /
bug-fix \ C-D /
\ /
release B--*--*--F
在此，B＆amp; C从A分支，E是 bug-fix 上的提交D合并提交到主，G是发布时提交F的合并提交进入 master 。
如果在错误修复和发布中更改了相同的文件，则可能会出现合并冲突。如果在G中使用git merge --ours，则在E处所做的更改可能会丢失。
可以通过分支主服务器和合并版本来处理合并，然后将这个一次性分支重新定位回主服务器。只有在流程得到良好控制的情况下才能执行此操作，例如，指定一个人将所有合并为主。
此时，G将不完全像F，它还将包括在E的错误修复提交中引入的更改。
还可以将错误修复合并到发布以及主，这将使F和G再次相同。但是，最佳做法是永不合并。这意味着，在图中布置的顺序中的分支（在顶部更稳定），合并应始终从下部分支到上部分支。这有两个主要好处，第一个好处是稳定代码不会合并到不太稳定的代码中，而分支保持纯，因为它们只包含与它们引入的功能相关的更改。例如，如果D合并到发布，则需要与发布一起进行测试，然后发布包含其引入的功能和更改中的更改集-set修复错误。
为了防止出现问题，我总是检查更稳定的分支，将较不稳定的分支合并到其中并从那里开始。
另请注意，--ours是已签出的分支，--theirs是要合并的另一个分支。当您更改合并的方向时，它们所引用的更改将被交换
答案 1 :(得分：2)
发布和master在合并后不可能有所不同。两个分支都指向同一个提交，合并提交将分支绑定在一起。因此它们完全相同。
如果要确保发布分支的内容成为主分支的内容，则需要使用我们的合并策略。这忽略了主分支中的更改，只是很好地取代了主分支的旧历史。所以你要做
git checkout release
git pull --strategy=ours . master
答案 2 :(得分：1)
你想要的是“我们的”合并策略。正如the git merge man page中指出的那样，它将始终使用合并的“我们的”一面并忽略“他们”方面的所有内容。它明确提到当一方完全取代另一方时使用它。
编辑：请注意，“递归”策略有“我们的”策略和“我们的”选项。您需要前者，策略和不 策略选项。