我们已经使用git-flow一段时间来开发软件框架了。我们将master和development分支放在一个存储库中。
最近，不同的客户开始有兴趣购买框架，这需要为每个客户定制框架。
到目前为止，我们从主站为每个客户分支一个新的feature-customerXYZ分支，在那里进行定制，并在定制完成后保持分支打开(这可以防止产品master/development分支从定制中"感染")。
与此同时，框架本身的开发继续在产品master、development、features、hotfixes和release分支上使用通常的 git-flow 工作流。
在这种情况下，我认为我们的工作流程无法以最佳方式处理两种常见情况：
-
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分支？
虽然理论上可以按照@VonC的建议在专用分支机构中保持客户偏差，但我敢说这在技术上非常困难并且无法扩展。
是的，你可以有作业(在 Jenkins 或其他东西中)会自动根据主分支重新调整你的偏差，但是当涉及到工具时，你只能靠自己了。至少要为以下情况做好准备：
- 变基会因冲突而失败- 很简单，git 会让你知道
- 变基将成功，但结果将包含逻辑冲突 - 这需要良好的测试覆盖率，因为没有工具能够警告您
相反，我建议尽量减少偏差，并在这样做之后，将它们全部并排放在一个分支中。
如果项目由模块组成，这通常是可能的。你没有提到你的项目的任何细节，但大多数语言都支持某种形式的模块化，所以我希望这也是你的情况。
这样，您可以尝试将偏差的扩展点集中到最小模块(理想情况下一个)，并在项目中具有这些模块的多个变体。
优点是显而易见的：
- 很简单
- 您的 CI 易于配置，可一次构建所有模块(=客户偏差)
- 您可以对它们运行测试，并轻松确定哪个测试是针对单个客户的，哪些是通用的，哪个特定于偏离的功能而不是客户
- 此外，您不必因此锁定分支模型，并且仍然可以使用 git-flow 或任何适合您需求的东西。
唯一的缺点是，当您只为一个客户发布项目(带有标记和其他仪式)时，您也会为所有其他客户发布项目。这通常没什么大不了的，另一方面，它激励了在功能上做出偏差，这很好。
为了尽量减少偏差，我推荐以下技术：
- 一些偏差可以通过配置选项更好地表示
- 其他的可能特定于功能而不是特定于客户
- 最好的是，一些偏差可能会被拒绝 - 尽管这几乎是不可能的
总而言之 -最小化偏差并并排构建它们。
将代码库分散到多个主分支(每个客户)将很快变得不可维护。
还使用拉取请求来合并从
feature-customerXYZ到开发的整体有效提交？
是的。
因此，项目维护者可以选择代码的哪些部分对产品主/开发有用？
否：项目维护者应该只接受合并(快进)的 PR，并运行测试来验证 PR 是否正常工作。
他/她不负责选择零件：只有开发人员应该选择它们(因为他/她知道需要向dev/master公开的内容。
因此，对于情况 1，仍然需要挑选或变基，以便创建一个专用分支(与功能分开)，然后通过 PR 提交给 dev 或 master 进行验证。
对于案例 2，修补程序应合并以开发，并且每个功能分支都可以在自己的时间基于最新的开发状态，因此包括 hostfix