简短概述
我们是产品公司，我们正在为50多个客户提供解决方案，他们每个月都在增长，我们有相当简单的分支模型，我想在可能的情况下升级。
模型
我们正在做敏捷，因此我们有冲刺和释放。每个月或两个我们都从 Master 开设新的版本分支，该分支将稳定，然后将其提供给对其中功能感兴趣的客户。到目前为止，一切都很好。在开发过程中，创建了新客户。假设我们开始在客户端上工作 a ，我们决定该客户端将使用某些版本，假设release/1.0，所以我们制作分支release/A_1.0，然后开始开发，一旦完成，我们将合并release/A_1.0 -> release/1.0，我们从release/1.0分支部署到生产。
在我继续解释问题之前，我将设定一些我们要保留的规则：
- 一旦
release分支开放，master永远不会合并到那里。 -
release/{client}_{version}分支有时会使用release/{version}分支(版本号应匹配(。 - 只有
hotfix分支合并为release/{version}分支。 - 在打开新的
release/{version}分支机构2-3之前，先前的版本release分支已合并到master，因此这些先前版本的所有热点也都在新版本中。 - 一旦打开
release/{version}分支，就不允许先前版本的hotfix。
问题在哪里？
tbh问题是糟糕的计划，但这会发生，因此无法避免。假设我们与客户协商(b(，我们决定给他们1.0版，这将打开一个分支机构，使其在这个分支机构的时间里开发此客户时，这将使该分支机构逐渐过去，而我们的产品团队Sprint则打开了另一个release，因为实例1.1.客户的开发过程需要足够的时间才能打开，如果不是一个或三个新的release/{version}分支。因此，如果发生这种情况，并且客户可能会决定与较新版本一起上线(例如，1.3-以前是为1.0开发的(。现在必须要做的是，我们需要从release/1.3开设分支机构，然后合并以前打开的分支 - 这将使release/B_1.0 --> release/B_1.3合并，这可以是痛苦要完成。为什么？
因为
release/B_1.0偶尔使用release/1.0更新 这意味着版本1.0的所有热点都将在release/B_1.0(由于某些hotfix对 客户的发展(以及合并的时间release/B_1.0 --> release/B_1.3这将包括所有这些热点 从release/B_1.3中的1.0版，后来介绍release/B_1.3 --> release/1.3合并时，它们将包含在版本1.3中 这是禁止的。
我在这种情况下做什么？
i樱桃挑选所有提交/合并，在 release/B_1.0中，不是来自 release/1.0的hotfix，to release/B_1.3中的 CC_29，但这确实可以耗时，并且由于git历史的工作方式，也可以犯错。<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<</p>
我建议可以将这些客户分支锁定以进行投入，因此只有合并才进入那里，当可以合并时，我可以轻松地挑选相关分支的合并(忽略release/{version}的合并(，而不用担心关于离开尾随的提交，但这意味着在这个分支机构工作的每个人都必须建立自己的分支并将其合并，这在我看来会减慢开发过程。
您还有其他建议可以缓解这种合并吗？
为什么不为不同的git存储库管理这些客户端？
在Git回购中管理所有客户似乎有效，但实际上并非如此。它基于所有客户都具有相同的requriemnts/bugs，否则您必须协商它们以与对方同步。
因此，您最好单独管理它们。即使两个客户具有相同的功能，您也可以轻松地使用交叉存储库：
# In repoA
git remote add B <URL for repo B> -f
gitk --all # find the commit of repoB you want to use in repoA
git cherry-pick <commit in repoB>