我们使用 Gitflow 进行 Web 构建，我有一个关于hotfixes应该如何工作的问题。但首先我应该解释一下，我们并没有完全使用正常的 Gitflow 工作流程。
我知道通常你会分支你的features，他们会develop在完成后合并到，你会创建你的release，release合并到master并部署它，作为一个实际的“版本化版本”。
但是，由于这是客户工作，我们不进行“发布”，而是在需要时部署功能，因此我们分支的更改会临时feature合并到其中。master
这确实引起了问题，因为feature分支是从develop前面分支出来的master；将这些feature分支master合并到会将其他更改合并到master（分支时尚未出现的develop更改feature）master。我们知道这不是 Gitflow 的设计方式，但我们需要某种分支模型，所以我们（某种程度上）通过挑选提交而不是合并分支来解决这个问题。
所以，我理解这些问题，我不相信它们会导致我现在遇到的问题，但以防万一，这就是我们使用它的方式。但是我的问题是：
hotfixes 应该怎么合并？
在我的脑海中，场景是：
master是“生产”develop领先于master
然后，您想要修补hotfix分支的直接问题。在 Gitflow 中，这从 分支master，当你完成时hotfix，它被合并到master 和 develop
但这怎么不会造成巨大的问题呢？
最近，我尝试创建一个hotfix以更改一个文件中的单行副本。我完成了hotfix，并且更改合并到master没有问题，但是当它厌倦了合并到 时，它创建了一个巨大的 35 个文件差异，由于和develop之间的差异，我没有接触过的文件中有几个合并冲突。developmaster
我知道这是因为您正在合并hotfix 分支，该分支本身是从分支到分支的，而master不是develop具体的更改或单次提交，所以我理解为什么会出现大规模的合并提交/冲突。
但是，我不明白的是，考虑到这一点，hotfixes“在现实世界中”如何工作，考虑到它们master是develop从master. 这就是为什么我认为我们使用 Gitflow 的方式不是问题的原因，因为无论我们的非标准部署过程如何，develop都会领先于我们 - 我不明白为什么无论项目如何，这都不会引起巨大的头痛master或确切的工作流程。
对我来说似乎没有意义的是，您hotfix可能只是将 a 更改true为 afalse或更改电子邮件地址等简单的事情，但是要进入master，您可能必须与大量的合并冲突作斗争。这只是标准行为吗？这就是hotfixes工作方式吗？如果您必须坐下来解决大规模的合并冲突，那就这样吧？只是愉快地选择一个提交不是更容易吗？似乎有如此巨大的空间为可能如此微小的变化引入错误 - 您正在处理两个分支，它们可能相距数月和数百次提交。
我可能只是误解了 的过程hotfixes，但如果我是，我不确定是哪一点。
