1

简要概述

我们是产品公司，我们为 50 多个客户提供解决方案，他们每个月都在增长，我们有相当简单的分支模型，如果可能的话，我想升级它。

该模型

我们正在做敏捷，因此我们有冲刺和发布。每个月或两个月，我们都会从master开放新的发布分支，该分支将稳定下来，稍后将提供给对其功能感兴趣的客户。到目前为止，一切都很好。在开发过程中会创建新的客户端。假设我们开始在客户端A上工作，并且我们决定该客户端将使用某个版本，假设我们创建分支并在那里开始我们的开发，一旦完成，我们合并->并从分支部署到生产客户。release/1.0release/A_1.0release/A_1.0release/1.0release/1.0

在我继续解释问题出在哪里之前，我将制定一些我们遵守的规则：

  • 一旦release分支打开master，就永远不会在那里合并。
  • release/{client}_{version}分支偶尔会用release/{version}分支更新（版本号应该匹配）。
  • 只有hotfix分支合并到release/{version}分支中。
  • 在打开新release/{version}分支之前 2-3 个以前的版本release分支被合并到，master因此这些以前版本的所有修补程序也都在新版本中。
  • release/{version}分支打开后，不允许使用以前版本的修补程序。

问题出在哪里？

Tbh 问题是糟糕的计划，但这种情况发生并且无法避免。假设我们与客户（B）进行了谈判，我们决定给他们 1.0 版本，这将打开一个分支，release/B_v1.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（这是无法避免的，因为某些修补程序对客户端的开发至关重要），当需要合并时， release/B_1.0 --> release/B_1.3这将包括 1.0 版的所有这些修补程序在引入合并release/B_1.3后，release/B_1.3 --> release/1.3它们将包含在 1.3 版中，这是被禁止的。

在这种情况下我该怎么办？

我会挑选所有提交/合并，这些提交/合并是来自 , 的，但release/B_1.0不是来自release/1.0, into的修补程序，release/B_1.3但这可能非常耗时，而且由于 git 历史的工作原理，也可能会犯错误。

我建议可以锁定这些客户端分支以进行提交，因此只有合并进入那里，当可以进行这种合并时，我可以轻松地只从相关分支中挑选合并（忽略来自的合并release/{version}），而不用担心留下尾随提交，但这意味着在这个分支中工作的每个人都必须创建自己的分支并将其合并到其中，在我看来这会减慢开发过程。

您还有其他可以简化此类合并的建议吗？

4

1 回答 1

1

为什么不为不同的 git 存储库管理这些客户端呢？

在 git repo 中管理所有客户端似乎很有效，但实际上并非如此。它基于所有客户端都具有相同的要求/错误，或者您必须协商它们以与其他客户端同步。

所以你最好分开管理它们。即使两个客户端具有相同的功能，您也可以轻松地跨存储库使用这些功能：

# 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>
于 2017-06-08T08:19:04.877 回答