如何在单体库中为产品进行版本控制？

Question

我一直在自学有关单体仓库的技术，因为我认为它是我们团队和项目当前状态的一个很好的解决方案。我们有多个 Web 产品（客户门户、内部门户、API、核心共享代码）。

但我遇到的问题是版本控制。

当所有项目和产品都在单体仓库中时，应该采用哪种版本控制策略呢？

• 采用适用于所有的版本？
• 使用独立版本控制的 Git 子模块（这有点违背了单体仓库的意义）？
• 还有其他策略吗？

从持续集成的角度来看，如果在 A 项目中提交了某些更改，是否应在所有项目中启动整套测试以确保没有出现问题，即使并没有对依赖/共享模块进行更改？

- justinledouxweb

---

你应该清楚地提到你使用的版本控制系统（看起来是git）和构建工具。还有你使用的发布工作流程是哪种类型。另外，一个问题中包含两个问题对于stackoverflow来说不太好。 - tkruse

这也许对您有所帮助：https://dev59.com/qFYN5IYBdhLWcg3whIbz#56558343 - Aage

Answer 1

当所有项目和产品都在单个代码仓库中时，版本控制策略应该是统一的。以下是一些原因：

- 发布产品时，可以将整个分支标记为“release-x.x.x”。如果出现错误，您不需要检查“YYY使用的XXX版本是哪个版本”。 - 这也使得更容易强制要求XXX的x.x.x版本使用YYY的x.x.x版本。实质上，使您的项目保持同步。当然，如何做取决于您的项目使用的技术。

从CI的角度来看，如果在项目A中提交了某些内容，是否应启动所有项目的测试套件以确保没有任何问题，即使没有对依赖项/共享模块进行更改？

如果测试执行时间不长，则不会有任何危害。我绝对建议这样做。您的测试运行得越频繁，就越能早日发现与时间或环境有关的错误。

如果出于某种原因不想始终运行测试，则可以查询您的VCS并编写一个脚本，根据更改的内容有条件地触发测试。这在您的VCS和CI服务器之间的集成方面非常重要。

- bitshift

---

这个答案深入假设monorepo中的所有项目都彼此相关。这里的关注点是受到如下问题的驱动：XXX是否使用YYY版本x.x.x？如果monorepo中的代码子段在逻辑上互不相关，那么就会有非常不同的问题，并且一个子项目谱系的版本控制不应与另一个子项目谱系的版本控制相连接。 - ely

例如，想象一下有人将PostgreSQL和TensorFlow的所有源代码放入同一个仓库中。现在每当PostgreSQL需要新版本时，TensorFlow也需要一个空操作版本，其中除了要将其版本增加以保持整个仓库的总体版本外，其他什么也不变。基于发布标记的自动生成更改说明将成为一项巨大的麻烦事。现在假设您还将所有Keras源代码添加到同一个仓库中，以确保特定版本的Keras使用的TensorFlow版本真正重要，但与Postgres的版本无关。 - ely

你觉得@Ely的解决方案会是什么样子呢？你谈论的情境正是我正在努力理解的。单个版本用于单个存储库中的不同应用程序是没有意义的。 - PaulT

嘿@PaulT，你最终是怎样允许在一个单体仓库内为不相关的项目使用不同版本的呢？ - John

我正在使用 Lerna 管理我的 monorepo，它只在项目内部（或其依赖项内部）发生了更改时才升级版本号。这对我来说效果很好，尽管我的 monorepo 目前规模较小。 - PaulT

强制使用版本并不是一个优势 - 优势在于您无需查找依赖项的最新版本，这是一个快速累加的负担。因此，此答案中的同步部分应相应地重新编写。 - linuxUser123