通常在Git Flow中,将一个
release
分支合并到
master
时不会出现冲突。原因是
release
分支应始终与
master
完全同步,可能只有一些空的合并提交除外。请注意,当将
release
或
master
合并回
develop
时可能会出现合并冲突。希望这种情况很少见,但在同时开发两个不同分支并最终合并的正常过程中(例如在
develop
上进行功能开发和在
release
上进行错误修复),这种情况是可能的。
Git Flow的使用规则要求在任何时候将
release
分支合并到
master
时遵循以下规则:
release
被合并到master
使用的是常规合并方式,而不是rebase或squash。此外,Git-Flow强烈建议使用merge --no-ff
来保留部署历史记录,许多PR工具默认使用--no-ff
进行常规合并。
在将release
合并到master
后,您应该立即将release
合并到develop
,如Git Flow所述,或者您可以将master
合并到develop
。我更喜欢后者,这样master
上的新合并提交将立即传递到develop
,这意味着develop
和下一个release
分支在状态和提交方面都与master
完全保持同步。如果您选择将release
合并到develop
,随着时间的推移,您将在master
上积累多个空的合并提交,最终在未来进行热修复时,所有这些提交将一次性传递到develop
。
对于一个“hotfix”分支,规则是类似的,但是在将“hotfix”合并到“master”之后,如果存在“release”分支,则应将“master”合并到“release”,如果没有待处理的发布分支,则应将其合并到“develop”。
如果始终遵循这些规则,在将“release”合并到“master”时将不可能发生冲突。
关于您的具体情况的其他说明:
我们一直没有做的一件事是将主分支合并回开发分支。
如上所述的规则#2,这是必需的。如果您跳过此步骤,则在“release”分支上的任何新错误修复可能不会传回“develop”,这意味着下一个“release”分支可能会缺少这些错误修复。如果您从“release”而不是“master”部署,您实际上可能会撤销下一个发布中的这些错误修复。此外,这将为下次将“release”合并到“master”打开冲突的大门,而通常情况下是不可能的。
我们尝试过不同的合并策略,如rebase no fast-forward、squash commit、基本合并等等。但似乎都没有关系。
关于合并策略的类似规则与上述规则#1有关,这适用于Git的一般情况,而不仅仅是Git Flow:
Git合并的经验法则:当将分支source合并到分支target时,如果source是一个长期存在的共享分支,则不应该重写该分支。
这意味着在执行"Git Flow"合并,如将release合并到master,将master合并到develop等操作时,永远不要使用rebase或squash,这两种方法都会重写分支上的提交。应始终使用常规合并,在Git Flow中,建议即使可以进行快进合并,也要使用--no-ff。如果重写共享分支,将导致未来合并中的不必要冲突。
注意,在将“feature”或“topic”分支合并到共享分支时,可以使用rebase和squash,因为这些分支不是共享的,一旦合并到共享分支后,它们可以被删除。特别是在rebase时,如果有多个提交,Git Flow建议在rebase之后仍然强制进行合并提交(有时称为“半线性合并”),以保留哪些提交是特性的历史记录。而squash和单提交特性没有额外的历史记录需要保留,因此不需要额外的合并提交。
然后,为了尝试一下,我们从开发分支创建了一个PR到主分支,我认为这应该没有冲突,但是我们发现大约60-70%的文件存在冲突。
只要开始遵循上述两个Git Flow规则,这个问题就会消失。顺便说一下,Git Flow没有记录过将“develop”合并到“master”的情况;相反,你应该有一个中间的“release”分支。(但是如果你的发布分支在从“develop”创建后没有任何新的提交,这种情况是可能发生的。)
master
分支合并回develop
分支(或者至少将release
分支合并回develop
,这几乎是一样的)。在Git Flow中,你也不会将develop
分支合并到master
分支,而是使用一个中间的release
分支。如果你在每次发布后不将master
分支(或者至少是release
分支)合并回develop
分支,你将遇到这里描述的问题。 - undefineddevelop
合并到release
并成功,然后将release
合并到master
,很有可能也会成功。之后,所有位于develop
中的提交已经在develop
中了 - 不需要再次合并。日常例行合并只从develop
合并到topic
分支,只是为了与最新的更改保持一致,并避免将冲突合并到develop
中。其他工作(develop
->release
->master
)应该顺利进行。这是基于实践的,但我并不坚持这种方式。 - undefinedrelease
分支合并到master
之前没有任何新的提交。(事实上,我认为这种情况很少见。)一旦release
分支上有一个单独的错误修复,它必须回溯到develop
分支,否则在后续的发布中可能会被撤销。 - undefined