将版本合并到master中,没有产生差异

Question

在工作中,我们有一个基于git流的git工作流.我们有3个主要分支:dev,release和master

Dev是我们目前正在开发的东西,master就是我们在生产和发布中所拥有的是当我们正在进行发布并进行最后的bug修复时.当发布准备就绪时,发布分支将合并到master中并推送到生产中.

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

问题是现在我们如何确保发布分支中的代码实际上是合并后的主代码？换句话说,release和master之间应该没有差异(合并之后).

当从发布分支合并到master时,我们也不想处理冲突,因此任何这些都应该自动处理.

Answer 1

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

合并冲突是与分支机构合作时的一揽子协议; 它们会发生,只需调整您的工作流程即可独立处理它们,以尽量减少任何不利影响.

为了说明这一点,请考虑以下情况:生产中存在已修复错误的现有版本,并且已准备好将发布分支移至生产(合并为主数据库).它看起来像这样:

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

在这里,B&C从A分支,E是提交D的合并提交,bug修复到master,G是提交F的合并提交,发布到master.

在G中,如果在bug-fix和release中都更改了相同的文件,则可能会发生合并冲突.如果git merge --ours已在G处使用,则在E处所做的更改可能会丢失.

可以通过分支主服务器和合并版本来处理合并,然后将这个一次性分支重新设置回主服务器.只有在流程得到良好控制的情况下才能执行此操作,例如,指定一个人将所有合并为主人.

此时,G将不完全像F,它还将包括在E中的bug修复提交中引入的更改.

也可以将bug-fix合并到release和master中,这将使F和G再次相同.但是,有一种最佳做法,即永不合并.这意味着,在图中布置的顺序中的分支(在顶部更稳定),合并应始终从下部分支到上部分支.这有两个主要好处,第一个好处是稳定代码不会合并到不太稳定的代码中,而分支保持纯粹,因为它们只包含与它们引入的功能相关的更改.例如,如果D被合并到发布中,则需要与发布和发布一起进行测试,然后包含其引入的功能的更改集和错误修复的更改集.

为了防止出现问题,我总是检查更稳定的分支,将较不稳定的分支合并到那里并从那里开始.

另外,请注意,--ours这是检出的分支,是--theirs要合并的另一个分支.当您更改合并的方向时,它们所引用的更改将被交换.