哪个 git 工作流用于产品开发和产品定制
Which git workflow to use for both product development and product customization
我们已经使用 git-flow 一段时间来开发软件框架。我们在单个存储库中有 master 和 development 分支。
最近，不同的客户开始对购买框架感兴趣，这需要为每个客户定制框架。
到目前为止，我们从 master 为每个客户分支了一个新的 feature-customerXYZ 分支，在那里进行了自定义并在自定义完成后保持分支打开（这防止了 'infection'来自自定义的产品 master/development 分支）。
与此同时，框架本身的开发在产品 master、development、features、hotfixes 和 release 个分支。
在这种情况下会发生两种常见情况，我认为我们的工作流程无法对其进行最佳处理：
feature-customerXYZ 分支的开发可以包含值得在产品 master/development 分支中实现的提交。由于 feature-customerXYZ 分支永远不会关闭，这些提交必须 rebased 或 cherrypicked 到产品分支，这需要在定制后进行额外的工作并且容易出错。
在 feature-customer 分支打开时发现的修补程序由 git-flow 通过合并打开的 hotfix 分支后仅修复到产品 [=12] 来处理=] 和 development 分支，但没有合并到打开的 feature-customer 分支中（更准确地说：它们没有合并到所有打开的 feature 分支中）。
是否有 git 工作流程可以简洁地处理此问题？是否有一个聪明的替代方案来代替 merge、cherrypick 或 rebase 对产品 master/develop 或开放 feature 分支的提交, 分别?
also use pull requests for merging the overall valid commits from feature-customerXYZ to develop?
是的。
So the project maintainer can select which parts of the code are useful for the product master/develop?
否：项目维护者应该只接受容易合并（快进）的 PR，并且 运行 测试以验证 PR 是否有效。
He/she 不负责 selecting 部分：只有开发人员应该 select 它们（因为 he/she 知道什么需要暴露给 dev/ master.
因此，对于情况 1，仍然需要 cherry-pick 或 rebase，以便创建一个专用分支（与功能分开），然后通过 PR 提交给 dev 或 master 进行验证。
对于情况 2，hotfix 应该合并到 develop，每个功能分支都可以在自己的时间 rebase on the latest develop state，因此包括 hostfix
虽然理论上可以像@VonC 提议的那样在专门的分支机构中维护客户偏差，但我敢说这在技术上非常困难并且无法扩展。
是的，你可以有一些工作（在 Jenkins 或其他东西中）会自动将你的偏差重新设置为 master 分支，但在工具方面，你只能靠自己了。至少要为以下情况做好准备：
- rebase 将 因冲突而失败 - 很简单，git 会让你知道
- rebase 会成功，但结果将包含逻辑冲突 - 这需要良好的测试覆盖率，因为没有工具能够警告您
相反，我建议最小化偏差，然后将它们并排放在一个分支中。
如果您的项目由模块组成，这通常是可能的。您没有提及项目的任何细节，但大多数语言都支持某种形式的模块化，所以我希望这也是您的情况。
这样，您可以尝试将偏差的扩展点集中到最小模块（最好是一个），并在项目中包含这些模块的多个变体。
优势明显：
- 很简单
- 您的 CI 易于配置，可以一次构建所有模块（=客户偏差）
- 您可以 运行 对它们进行测试，并轻松决定哪个测试是针对单个客户的，哪个是通用的，哪个特定于偏离的功能而不是客户
- 此外，您不必因此锁定您的分支模型，并且仍然可以使用 git-flow 或任何适合您需要的东西
唯一的缺点是，当您只为一个客户发布您的项目（带有标签和其他仪式）时，您也会为所有其他客户发布项目。这通常没什么大不了的，另一方面，它会激励在特征方面做出偏差，这很好。
为了尽量减少偏差，我推荐以下技巧：
- 配置选项可以更好地表示一些偏差
- 其他人可能是特定于功能而不是特定于客户的
- 最好的一个，有些偏差可能会被拒绝——尽管这几乎不可能
总结一下 - 尽量减少偏差并并排构建它们。
将您的代码库分散到多个主分支（每个客户）将很快变得无法维护。
我们已经使用 git-flow 一段时间来开发软件框架。我们在单个存储库中有 master 和 development 分支。
最近，不同的客户开始对购买框架感兴趣，这需要为每个客户定制框架。
到目前为止，我们从 master 为每个客户分支了一个新的 feature-customerXYZ 分支，在那里进行了自定义并在自定义完成后保持分支打开（这防止了 'infection'来自自定义的产品 master/development 分支）。
与此同时，框架本身的开发在产品 master、development、features、hotfixes 和 release 个分支。
在这种情况下会发生两种常见情况，我认为我们的工作流程无法对其进行最佳处理：
feature-customerXYZ分支的开发可以包含值得在产品master/development分支中实现的提交。由于feature-customerXYZ分支永远不会关闭，这些提交必须rebased或cherrypicked到产品分支，这需要在定制后进行额外的工作并且容易出错。在
feature-customer分支打开时发现的修补程序由git-flow通过合并打开的hotfix分支后仅修复到产品 [=12] 来处理=] 和development分支，但没有合并到打开的feature-customer分支中（更准确地说：它们没有合并到所有打开的feature分支中）。
是否有 git 工作流程可以简洁地处理此问题？是否有一个聪明的替代方案来代替 merge、cherrypick 或 rebase 对产品 master/develop 或开放 feature 分支的提交, 分别?
also use pull requests for merging the overall valid commits from
feature-customerXYZto develop?
是的。
So the project maintainer can select which parts of the code are useful for the product master/develop?
否：项目维护者应该只接受容易合并（快进）的 PR，并且 运行 测试以验证 PR 是否有效。
He/she 不负责 selecting 部分：只有开发人员应该 select 它们（因为 he/she 知道什么需要暴露给 dev/ master.
因此，对于情况 1，仍然需要 cherry-pick 或 rebase，以便创建一个专用分支（与功能分开），然后通过 PR 提交给 dev 或 master 进行验证。
对于情况 2，hotfix 应该合并到 develop，每个功能分支都可以在自己的时间 rebase on the latest develop state，因此包括 hostfix
虽然理论上可以像@VonC 提议的那样在专门的分支机构中维护客户偏差，但我敢说这在技术上非常困难并且无法扩展。
是的，你可以有一些工作（在 Jenkins 或其他东西中）会自动将你的偏差重新设置为 master 分支，但在工具方面，你只能靠自己了。至少要为以下情况做好准备：
- rebase 将 因冲突而失败 - 很简单，git 会让你知道
- rebase 会成功，但结果将包含逻辑冲突 - 这需要良好的测试覆盖率，因为没有工具能够警告您
相反，我建议最小化偏差，然后将它们并排放在一个分支中。
如果您的项目由模块组成，这通常是可能的。您没有提及项目的任何细节，但大多数语言都支持某种形式的模块化，所以我希望这也是您的情况。
这样，您可以尝试将偏差的扩展点集中到最小模块（最好是一个），并在项目中包含这些模块的多个变体。
优势明显：
- 很简单
- 您的 CI 易于配置，可以一次构建所有模块（=客户偏差）
- 您可以 运行 对它们进行测试，并轻松决定哪个测试是针对单个客户的，哪个是通用的，哪个特定于偏离的功能而不是客户
- 此外，您不必因此锁定您的分支模型，并且仍然可以使用 git-flow 或任何适合您需要的东西
唯一的缺点是，当您只为一个客户发布您的项目（带有标签和其他仪式）时，您也会为所有其他客户发布项目。这通常没什么大不了的，另一方面，它会激励在特征方面做出偏差，这很好。
为了尽量减少偏差，我推荐以下技巧：
- 配置选项可以更好地表示一些偏差
- 其他人可能是特定于功能而不是特定于客户的
- 最好的一个，有些偏差可能会被拒绝——尽管这几乎不可能
总结一下 - 尽量减少偏差并并排构建它们。
将您的代码库分散到多个主分支（每个客户）将很快变得无法维护。