git - gitflow 修补程序应该如何工作？

Question

我们使用 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 的过程，但如果我是，我不确定是哪一点。

Answer 1

对于 this link 中的第一张图片



我不明白为什么会有很多冲突。 merge 到 develop 的更改只是最新的修补程序，可能是以前的修补程序，如果它们由于某种原因没有轮到它们 merge 。

(虽然我宁愿将 hotfix merge 到 master ，然后它们 merge master 到 develop ，而不是直接 merge hotfix 到 develop ，只是为了避免交叉，但不应该 merge 变化很大)