Question

我想知道将“修补程序”集成到Git工作流程中的赌注方式是什么。

似乎所有针对Git工作流教程的建议都建议将修补程序拉到主分支和开发/功能分支。

但是，修复生产状态的修补程序又如何在开发分支中替换/更改/重新计算？

为了给你一个想法，我的意思是：

说，您已将以下代码部署到生产

function fetchDogs() {
   return cats;
}

两周后，您发现自己混淆了cats和dogs。您为它创建一个修补程序分支，将cats替换为dogs，将其推送到主站并进行部署。所以，非常好。

然而，想象一下，与此同时你注意到你的函数结构无论如何都是低效的，所以在你的开发分支上你已经把它改成了：

function fetchAnimals(whichAnimal) {
       return animals[whichAnimal];
    }

但是，您无法部署，因为它尚未经过测试（或出于任何原因）。

因此，如果您将修补程序提取到开发分支，您可能会获得完全不必要且多余的合并冲突。（在我的项目中经常发生的事情是合并冲突未得到足够仔细解决导致代码中出现不需要的工件。）

但是，如果你没有拉它，你就不能再去掌握了。

如何解决这种情况？

（在写完我的问题之后，我意识到这个问题How should gitflow hotfixes work?可能会解决同样的问题。但是，由于这个问题没有真正的答案，不过我还是试一试。。）

Answer 1

合并行为可以做几件事。

首先，显而易见的是：默认情况下，它会将（在这种情况下）修补程序的文本更改应用于（在本例中）dev分支。

其次，正如您所指出的，它有助于git理解（在这种情况下）修补程序所做的更改（在本例中）是dev分支。

但它可能是最重要的事情：它将在修补程序上进行的代码更改（因为hitfix / dev merge base）与dev上的更改（自合并基础）并排放置并提供有机会审核结果并确保在修补程序中所做的更改实际上实际上是在开发中的。

我认为最后一点是逻辑合并操作，而文本更改的混合只是通常完成该任务的一个物理操作。

现在，您反对说如果不需要合并，并且某人错误地解析了合并，则会引入新的错误。好吧，好吧......但这是另一种看待它的方式。分析dev中的更改和修补程序中的更改，并确定不需要物理合并，这只是执行逻辑合并的另一种策略。并且，由于您的分析可能不会考虑所有内容，因此此策略也可能会承认错误。（而那些可能是令人尴尬的错误，因为你已经修复了它们。）除此之外，它与物理合并相比还有两个缺点：

首先（再次注意）它没有给git一种方法来知道在dev中考虑了这个修补程序。将修补程序合并到dev中具有文档值，即使您使用ours策略执行合并（即完全忽略此修补程序）。

其次，合并到dev对测试有影响。其性质的修补程序必须引入至少一个新的测试用例。这应该合并到您的代码库中，即使此修补程序中的所有生产代码都不相关。（如果重构改变了测试用例需要编写的方式，那就是合并的一部分。）此外，合并提交需要通过完整的测试套件运行（这也应该否定任何不良合并工作的担忧）会在此时引入错误。）

最重要的是，如果您的测试足够松散以伪造我刚才所说的任何部分，那么担心如何最好地合并修补程序只是争论在泰坦尼克号上制作躺椅的颜色。

我能想到的最后一个可能的反对意见是所谓的'邪恶的合并＆＃34;。如果以某种方式以后对dev 的更改可以避免修补程序，但默认合并会成功自动解析（我发现这种情况不太可能，但是为了参数... 。），然后产生非默认合并（通过使用类似ours的策略，或通过修改合并提交，或使用--no-commit，...）可能会导致一些麻烦操作。最大的担忧是变基，在这种情况下，我不认为这可能是一个问题。但如果它让您担心，您可以随时完成自动合并，然后使用后续提交来应用＆＃34;更正＆＃34;合并后的州。

适用于主/生产的修补程序，但不再适用于开发分支

1 个答案: