我们使用 Gitflow 进行 Web 构建,我有一个关于如何 hotfixes
的问题应该可以工作。但首先我应该解释一下,我们并没有完全使用正常的 Gitflow 工作流程。
我知道通常你会分支你的 features
,它们将 merge 为 develop
完成后,您将创建您的 release
, release
merge 为 master
然后将其部署为实际的“版本化版本”。
但是,由于这是客户端工作,我们不进行“发布”,而是在需要时部署功能,因此更改来自 feature
分支 merge 为 master
在临时基础上。
这确实引起了问题,因为 feature
分支来自 develop
这远远领先于 master
; merge 这些 feature
分支到 master
将其他更改 merge 到 master
(在 develop
分支时存在于 feature
中的更改尚未在 master
中)。我们意识到这不是 Gitflow 的设计方式,但我们需要某种分支模型,所以我们(某种程度上)通过挑选提交而不是 merge 分支来解决这个问题。
所以,我理解这些问题,我不相信它们会导致我现在遇到的问题,但以防万一,这就是我们使用它的方式。不过我的问题是:
怎么样 hotfixes
应该 merge ?
在我的脑海中,场景是:
master
是“生产”develop
领先于master
然后你想用
hotfix
修补一个直接问题。分支。在 Gitflow 中,这个分支来自 master
,当你完成 hotfix
,这被 merge 到 master
和 develop
但这怎么不会造成大问题呢?
最近,我尝试创建一个
hotfix
更改一个文件中的单行副本。我完成了hotfix
,并且更改 merge 为 master
没有问题,但是当它累了 merge 到 develop
,由于 develop
之间的差异,它创建了一个巨大的 35 个文件差异,其中包含我没有触及的文件中的几个 merge 冲突。和 master
.我知道这是因为您正在 merge
hotfix
分支,它本身是从 master
分支出来的, 进入 develop
,不是特别是更改或单次提交,所以我理解为什么会有大量的 merge 提交/冲突。然而,我不明白的是,考虑到这一点,如何
hotfixes
考虑到它们是从 master
分支出来的,因此“在现实世界中”完全可以工作。然后 merge 到develop
,这在设计上远远领先于 master
.这就是为什么我认为我们使用 Gitflow 的方式不是问题的原因,因为 develop
会领先于 master
无论我们的非标准部署过程如何 - 我不明白为什么这不会引起巨大的麻烦,无论项目或确切的工作流程如何。对我来说似乎没有意义的是你的
hotfix
可能就像更改 true
一样简单到 false
或更改电子邮件地址,无论如何,但要将其输入 master
,您可能不得不与大量的 merge 冲突作斗争。这只是标准行为吗?是这样吗hotfixes
工作,如果您必须坐下来解决大规模的 merge 冲突,那就这样吧?只是愉快地选择一个提交不是更容易吗?似乎有如此大的范围可以为可能如此微小的更改引入错误 - 您正在处理两个可能相距数月和数百次提交的分支。我可能只是误解了
hotfixes
的过程,但如果我是,我不确定是哪一点。
最佳答案
对于 this link 中的第一张图片
我不明白为什么会有很多冲突。 merge 到 develop
的更改只是最新的修补程序,可能是以前的修补程序,如果它们由于某种原因没有轮到它们 merge 。
(虽然我宁愿将 hotfix
merge 到 master
,然后它们 merge master
到 develop
,而不是直接 merge hotfix
到 develop
,只是为了避免交叉,但不应该 merge 变化很大)
关于git - gitflow 修补程序应该如何工作?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41716927/