git - 哪个 git 工作流用于产品开发和产品定制

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

最近，不同的客户开始对购买框架感兴趣，这需要为每个客户定制框架。

到目前为止，我们feature-customerXYZ从 master 为每个客户分支了一个新分支，在那里进行了定制，并在定制完成后保持分支开放（这可以防止定制对产品master/development分支的“感染”）。

与此同时，框架本身的开发继续使用产品、、、和分支上通常的 git- masterflowdevelopment工作流features。hotfixesrelease

在这种情况下会发生两种常见情况，我认为我们的工作流程无法以最佳方式处理：

分支的开发feature-customerXYZ可以包含值得在产品master/development分支中实现的提交。由于feature-customerXYZ分支永远不会关闭，因此这些提交必须是rebased或cherrypicked到产品分支，这需要在自定义之后进行额外的工作并且容易出错。
feature-customer在分支打开时发现的修补程序git-flow通过将修复后打开的hotfix分支仅合并到产品master和development分支来处理，但不会合并到打开的feature-customer分支中（更准确地说：它们没有合并到所有打开的feature分支中）。

是否有一个 git 工作流程可以简洁地处理这个问题？是否有一个聪明的替代方案来代替merge,cherrypick或者rebase分别提交到产品master/develop或开放feature分支？

标签： gitversion-controlgit-rebasegit-flowgit-cherry-pick

虽然理论上可以按照@VonC 的建议在专门的分支机构中保持客户偏差，但我敢说这在技术上非常困难并且无法扩展。

是的，你可以有一些工作（在 Jenkins 或其他东西中）会自动调整你对 master 分支的偏差，但是当涉及到工具时，你就得靠自己了。至少要为以下情况做好准备：

相反，我建议尽量减少偏差，然后将它们并排放在一个分支中。

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

这样，您可以尝试将偏差的扩展点集中到最小模块（最好是一个）中，并在项目中拥有这些模块的多个变体。

优点很明显：

唯一的缺点是，当你只为一个客户发布你的项目（带有标签和其他仪式）时，你也为所有其他客户做这件事。这通常没什么大不了的，另一方面，它激发了特征方面的偏差，这很好。

为了尽量减少偏差，我推荐以下技术：

总结一下 -尽量减少偏差并并排构建它们。

将您的代码库扩展到多个主分支（每个客户）将很快变得无法维护。