问题描述
我们正在开发一个被多个客户使用的应用程序，每个客户都有不同版本的应用程序。
我们的团队目前正在遵循 Git Flow 分支策略，但我们在维护单个主分支方面遇到了障碍。
例如：
- 客户 A 有 v1.1.2
- 客户 B 有 v1.1.4
我们在 v1.1.4 中为客户 B 修复了一个漏洞，并在主分支中将版本更新到 v1.1.5。 现在客户 B 要求在他们的版本中修复补丁，但目前不希望更新到 v1.1.4。 此修复程序随后被版本化为 v1.1.2.1（仍在其发布分支上）。
我们目前正在维护多个发布分支并根据需要引入功能分支，但我们认为从长远来看这是不可扩展的。
是否有推荐的解决方案或分支策略？
解决方法
也许您应该创建每个 x.x.x 版本的发布，同时修复您在 x.x.x.x 版本上的错误，并且您的客户可以使用此版本。 所以可以有很多 x.x.x 版本。你可以认为这个 x.x.x 版本有点重要。
,您是否尝试过寻找 oneflow 方法来从以前的版本创建新分支。
试试看这个https://www.endoflineblog.com/gitflow-considered-harmful
,有两个主要更新 - 新功能和安全更新。可以根据版本号为每个客户维护新功能。但是，安全更新可以作为补丁提供，从 v1.x.x 开始可用。这将使漏洞修复和功能更新分离。您可以将补丁放在特定的分支中，有人可以将他们的给定分支与安全补丁分支上的最新版本合并。
您可以在每次有新的安全补丁时发送电子邮件。
,我的建议是将您的软件组件移动到多个单独的存储库。
然后，您可以将它们作为不同状态的子存储库包含在不同的分支/存储库中（您可以让 tp 为每个客户创建一个分支或存储库）。