用于产品开发和产品定制的git工作流

Question

我们已经使用git-flow开发了一段时间的软件框架。我们将master和development分支放在一个存储库中。

最近，不同的客户对购买该框架产生了兴趣，这就需要对每个客户的框架进行定制。

到目前为止，我们从主程序中为每个客户创建了一个新的feature-customerXYZ分支，在那里进行了定制，并在完成定制后保持了分支的打开(这防止了产品master/development分支对定制的“感染”)。

与此并行，框架本身的开发继续使用产品master、development、features、hotfixes和release分支上通常的git流工作流。

在这种情况下，有两种常见的情况，我认为我们的工作流无法最优地处理：

1. feature-customerXYZ分支的开发可以包含值得在产品master/development分支中实现的提交。因为feature-customerXYZ分支永远不会关闭，所以这些提交必须是rebased或cherrypicked到产品分支，这需要在定制之后进行额外的工作，并且容易出错。
2. 在打开feature-customer分支时发现的修补程序由git-flow处理，方法是将修复后打开的hotfix分支合并到产品master和development分支，但不合并到打开的feature-customer分支中(更确切地说:它们不是合并到所有打开的feature分支中)。

是否有一个git工作流能够以简洁的方式处理这一问题？是否有一个聪明的替代方案，而不是merge、cherrypick或rebase分别提交到产品master/develop或开放的feature分支？

Answer 1

还可以使用拉请求合并来自feature-customerXYZ的总体有效提交来开发？

是。

因此，项目维护者可以选择代码的哪些部分对产品主/开发有用？

不:项目维护人员应该只接受简单的合并(快速转发)，并运行测试来验证PR是否有效。

他/她不负责选择部件:只有开发人员才应该选择它们(因为他/她知道需要向dev/master公开什么。

因此，对于案例1，仍然需要樱桃采摘或重基，以便创建一个专门的分支(独立于特性)，然后通过PR提交给开发人员或主开发人员进行验证。

对于例2，应该合并热修复以进行开发，并且每个特性分支都可以在自己的时间内进行以最新的发展状况为基础，因此包括主机修复。

Answer 2

虽然理论上可以像@VonC建议的那样在专用分支中保持客户偏差，但我敢说，这在技术上是非常困难的，而且是不扩展的。

是的，您可以有一些作业(在Jenkins或其他什么地方)，这些作业将自动将您的偏差与主分支重新定位，但是当涉及到工具时，您就只能靠自己了。至少，为下列情况做好准备：

• 重基将使与冲突失败-简单，git会让您知道
• 重基将使成功，但结果将包含逻辑冲突--这需要良好的测试覆盖率，因为没有任何工具能够警告您。

相反，我建议尽量减少偏差，在这样做之后，将它们保持在一个单独的分支中，并排。

如果您的项目是由模块组成的，这通常是可能的。您没有提到项目的任何细节，但是大多数语言都支持某种形式的模块化，所以我希望这也是您的情况。

这样，您可以尝试将偏差扩展点集中到最小模块(理想情况下是一个)，并在项目中拥有这些模块的多个变体。

好处显而易见：

• 很简单
• 您的CI易于配置为一次构建所有模块(=客户偏差)
• 您可以在它们上运行测试，并且很容易地决定哪个测试是针对单个客户的，哪个是通用的，哪些是特定于偏离特性的，而不是特定于客户的。
• 此外，您也不必因此而锁定分支模型，并且仍然可以使用git-flow或其他适合您需要的东西。

唯一的缺点是，当你只为一个客户发布项目(带有标记和其他仪式)时，你也会为所有其他客户发布项目。这通常并不是什么大问题，另一方面，它会促使偏差变得更有特色，这是很好的。

为了最大限度地减少偏差，我推荐以下技巧：

• 一些偏差可以更好地用配置选项来表示。
• 其他的则可能是特定于特性而不是特定于客户的。
• 最好的，一些偏差可能会被拒绝--尽管这是不可能的。

只是总结-尽量减少偏差，并建立他们的所有，并排。

将您的代码库扩展到多个主分支(每个客户)将很快变得不可维护。