我们是产品公司，我们为50多个客户提供解决方案，他们每个月都在增长，我们有相当简单的分支模式，如果可能的话我想升级。
我们正在做敏捷，因此我们有冲刺和释放。我们每个月或两个月都会从主开设新的发布分支，该分支将会稳定下来，之后将会提供给对其功能感兴趣的客户。到现在为止还挺好。在开发期间，将创建新客户端。我们假设我们开始在客户 A 上工作，我们决定这个客户端会使用某个版本，让我们说release/1.0所以我们创建分支{{1}我们在那里开始我们的开发，一旦完成，我们合并release/A_1.0 - ＆gt; release/A_1.0我们从release/1.0分支到此客户端进行生产。
在我继续解释问题所在之前，我将制定一些我们要遵守的规则：
release/1.0分支打开后release永远不会合并。master分支偶尔会使用release/{client}_{version}分支进行更新（版本号应该匹配）。release/{version}个分支合并到hotfix分支。release/{version}分支之前2-3先前版本release/{version}分支已合并到release，因此这些先前版本的所有修补程序也都在新版本中。master分支后，不允许使用以前版本的修补程序。 Tbh问题是糟糕的计划，但这种情况发生并且无法避免。
让我们说我们与客户（B）进行了协商，我们决定给他们1.0版本，这将打开一个分支，使它release/{version}，而我们在这个分支时间内开发这个客户端产品团队sprint打开另一个release/B_v1.0，例如1.1。有时，客户的开发过程需要足够的时间来打开产品（如果不是一个，而是两个或三个新的release分支。因此，如果这种情况发生在管理层，客户可能会决定使用更新的版本（让我们说1.3 - 之前它是为1.0开发的）。
现在要做的是我们需要从release/{version}为此客户端打开分支，然后合并先前打开的分支 - 这将合并release/1.3，这可以是 痛苦 待完成。为什么呢？
因为
release/B_1.0 --> release/B_1.3偶尔会更新release/B_1.0这意味着版本1.0中的所有修补程序都将在release/1.0（由于某些修补程序至关重要，因此无法避免 开发客户端）以及什么时候合并release/B_1.0这将包括所有这些修补程序 从release/B_1.0 --> release/B_1.3中的版本1.0开始，稍后在引入release/B_1.3合并时，它们将包含在版本1.3中 这是被禁止的。
我挑选所有提交/合并，这些提交/合并位于release/B_1.3 -->
release/1.3并且不是来自release/B_1.0的修补程序，而是release/1.0，但这可能非常耗费时间并且错误可能是由于git历史如何运作这一事实也是如此。
我建议这些客户端分支可以被锁定以进行提交，因此只有合并才能进行，当可以进行这种合并时，我可以轻松地从相关分支中选择合并（忽略来自release/B_1.3的合并并且不用担心留下尾随提交，但是这意味着在这个分支中工作的每个人都必须创建自己的分支并将其合并在一起，这在我看来减慢了开发过程。
你有其他任何可以减轻这种合并的建议吗？
答案 0 :(得分：1)
为什么不为不同的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>