我们在web构建中使用Gitflow，并且我对
我知道通常情况下，您会分支您的
然而，由于这是客户工作，我们不做"releases"，而是在需要时部署功能，因此我们的
这确实会导致问题，因为
因此，我了解这些问题，并且我不认为它们对我现在的问题有贡献，但以防万一，这就是我们使用它的方式。但是我的问题是：
在我的头脑中，情况是：
最近，我尝试创建一个
我知道这是因为您正在将
然而，我不理解的是，在这种情况下，
hotfixes的工作原理有疑问。但首先我应该解释一下，我们并没有完全使用常规的Gitflow工作流程。我知道通常情况下，您会分支您的
features，完成后它们会合并到develop中，您会创建您的release，release会合并到master中，您会部署它作为一个实际的“版本发布”。然而，由于这是客户工作，我们不做"releases"，而是在需要时部署功能，因此我们的
feature分支的更改根据需要按Ad-hoc方式合并到master中。这确实会导致问题，因为
feature分支是从超前于master的develop分支分支切出来的；将这些feature分支合并到master中将会将其他更改合并到master中（那些在feature分支切出时存在于develop中但尚未在master中）。我们知道这不是Gitflow的设计思想，但我们需要某种分支模型，所以我们通过挑选提交而不是合并分支（有点）解决了这个问题。因此，我了解这些问题，并且我不认为它们对我现在的问题有贡献，但以防万一，这就是我们使用它的方式。但是我的问题是：
hotfixes应该如何合并？在我的头脑中，情况是：
master是"production"develop超前于master
hotfix的分支。在Gitflow中，这个分支从master分支创建，并且在完成hotfix后，会被合并到master和develop分支中。但这不会引发大问题吗？最近，我尝试创建一个
hotfix，只是更改一个文件中的一行内容。我完成了hotfix，将更改合并到master时没有任何问题，但当它尝试合并到develop时，出现了一个巨大的35个文件diff，并且文件中有几个合并冲突，而这些文件与我没有做任何更改有关，这是由于develop和master之间的差异造成的。我知道这是因为您正在将
hotfix分支（自己是从master分支创建）合并到develop分支，而不是特定的更改或单个提交，所以我明白为什么会出现大量的合并提交/冲突。然而，我不理解的是，在这种情况下，
hotfixes如何在实际工作中完成，考虑到它们是从master分支创建，然后合并到设计上遥遥领先于master的develop分支。这就是为什么我认为我们使用Gitflow的方式不是问题所在，因为无论我们的非标准部署过程如何，develop都将超前于master - 我看不出为什么这不会在任何项目或确切的工作流程中引起巨大的麻烦。我觉得不太合理的是，你的 hotfix 可能只是一个简单的将 true 改成 false 或者更改电子邮件地址等等，但是为了将它合并到 master 分支中，你可能需要处理大量的合并冲突。这是标准行为吗？这就是 hotfixes 的工作方式吗？如果你必须花时间去解决巨大的合并冲突，那么这样做是否比仅仅挑选一个提交更容易呢？似乎为了实现一个微小的变化而引入错误的范围非常大 - 你要处理的是两个分支之间可能相隔数个月、数百个提交的情况。
也许我只是没有正确理解 hotfixes 的过程，但如果是这样，我不确定具体在哪里出了问题。
master分支（例如myHotfix1）分支，进行提交，并合并回master，则该合并可以解决为快进。因此，除非有人同时合并了其他内容，否则不可能遇到合并冲突。 Gitflow的一个重要点是将合并冲突解决在主题分支中，以便将拉取请求合并到公共分支（develop，release_x等）中可以快速转发。诀窍是保持所有私有/主题分支与其各自的基础更新。 - Cody Stott