问题标签 [monorepo]

在工作中，我们正在开发一个包含大量前端、后端和支持组件的大型应用程序。通常前端是用 C# 开发的，后端是用 Java 开发的，尽管后端的一部分也是用 C# 和可能后来的 C++ 开发的。

语言和平台的选择不是任意的；我们尝试权衡每个组件在开发时间、工具链成本、特定开发团队对语言的熟悉程度等方面的相对优点。但是，所有这些组件的共同点是，它们都是完整操作所必需的产品，并且它们是由独立的（但高度沟通的）团队同时开发的。

以前，我们使用 Team Foundation Server 编写 .NET 代码，使用 Subversion 编写 Java 代码；因为团队职责明确分离，除了将一个源代码树生成的二进制文件（在本例中为 WAR）放置在另一个源代码树中的不便以及保持分支和修订同步的高手动开销之外，这几乎没有造成什么问题。有了这个项目，团队之间的分离程度故意要小得多，分支/合并的数量预计会大大增加；因此，我们正在转向统一的 VCS，更具体地说是 Subversion。

这让我想到了问题的实质：如何有效地混合 Java 和 C# 代码？在实践中，我们将拥有依赖于 Java 代码库的 .NET 代码；Java 二进制文件需要运行除单元测试代码以外的任何东西（集成测试已经需要二进制文件，并且 QA、验收测试等当然也需要）。我们目前的想法是这样的：

这个想法是将整个源代码树放在一个分支下；.NET 代码依赖于 Java 代码，因此我们将在解决方案中添加一个构建后步骤，这将（很可能）调用 Java 组件的 ant 脚本。这允许对整个代码库（对于 .NET 开发人员）或仅对 Java 组件（对于 Java 开发人员）进行分支。

这个解决方案的问题是：

1. 当两个代码库中的一个变得如此之大以至于为每个分支复制它变得不切实际时会发生什么？（我们的想法：拆分为 .NET 和 Java 代码的单独存储库并使用 svn:externals，对此的任何输入将不胜感激）。
2. 我们使用 Eclipse 进行 Java 开发。我们如何管理“共享”工作空间（即哪些项目需要哪些组件、依赖关系图等）？到目前为止，我们拥有的 Java 组件相对较少，因此每个开发人员都可以同时将所有这些组件保存在工作区中。随着 Java 组件和 Java 开发人员的增加，我看不出我们如何才能继续这样做。关于如何在保持两个代码库之间同步的同时保持工作区版本化（la 解决方案文件）的任何建议？

我很想听听你的意见！

虽然这个问题似乎是重复的或许多以前的问题（以及数十篇涉及类似主题的博客文章），但我需要让您知道我正在寻找一种允许我编写脚本的方法。

• 所有分支和标签都应该合并
• 分支和标签应该加前缀以避免重叠
• 文件不会重叠，因为我们导入到新的子文件夹。
• 增量合并过程：以后能够合并新的存储库，因为我计划缓慢迁移到 monorepo 设置，一次一个存储库。

我正在尝试构建的脚本应该像这样工作：

这将假定目标存储库 (monorepo) 已在monorepo/文件夹中克隆，并且它没有任何本地更改。

例如，如果 foo.git 将有两个分支master和develop一个标签名称v1.0，在执行合并后，我希望在 monorepo 存储库中看到分支foo-master和foo-develop标签。foo-v1.0

我阅读了数十篇文章（或脚本），但到目前为止我还没有找到一篇解释如何获得它的文章。

澄清

• 如果我在 foo.git 存储库的根目录中有一个 README.txt，我希望在monorepo/subdir/foo/README.txt. 如果这些将成为大仓库的子目录（以前不存在的子目录），那是唯一允许我合并存储库而不会发生冲突的方法。

更新

虽然我还没有准备好说问题已经解决，但我最终编写了这个 bash 脚本，它应该在修补源存储库后执行合并。看看它https://github.com/ssbarnea/monorepo/blob/master/git-monorepo-add.sh

PS。一旦我有一个可靠的解决方案，我会尽快给出正确的答案，并通过许多存储库进行测试。

使用 Bash 和 git，我如何获得包含与上次分支合并到不同的文件的目录集合master？

更好的做法是一个匹配模式的更改集合，例如包含特定文件名，即构建一个包含更改目录的集合package.json和一个不同的更改包含集合requirements.txt。

我有一个proj使用子树的 monorepo 项目，该项目sub位于proj/sub. 我已经做出了大量涉及proj和的提交sub。如何sub有效地将相关更改发布到上游？

通常，我必须使用

git cherry-pick -x --strategy=subtree -Xsubtree=sub/ commit-ref

但是我已经提交了无数次，所以这是不可行的。如何将更改集成到sub一次？例如，创建一个大的压缩提交，它会带入sub我的 monorepo 中的相同状态。

相关：查看对子文件夹进行更改的提交，如何挑选一系列提交并合并到另一个分支

我们最近决定从 TFVC 迁移到 Git，我正在尝试找到设计新 Git 架构的最佳方式。

我们的代码是由独立但紧密耦合的模块组成的，让我们看一下以下项目：

• CommonLib1

• CommonLib2

• ApplicationA（使用CommonLib1）

• ApplicationB（使用CommonLib1& CommonLib2）

尽管CommonLib1/CommonLib2是完全独立的，但几乎 / 的每个新功能都需要修改ApplicationA/ 。ApplicationBCommonLib1CommonLib2

此外，在添加新功能时，我们希望创建一个跨越所有项目的单一分支。

据我了解，我有两个主要选择：

1. 为每个项目创建一个 repo，并在 / 中添加/CommonLib1作为CommonLib2子树。ApplicationAApplicationB

2. 为所有项目创建一个 Monorepo。

对于我的情况，最好的 Git 实践是什么？

很抱歉这个冗长的问题，但这是一个复杂的设置。我们的应用程序是 Monorepo 中的 SPA。该应用程序是一种“外壳”，可以将较小的单个应用程序加载到其中。我们的文件夹结构如下：

所以在这个结构中，“shell”应用程序是加载每个“app1”，“app2”等的应用程序。这意味着在shell应用程序中，存在对app1，app2等的依赖关系。但除此之外，每个个别应用程序也可以独立运行，而无需从 shell 运行。

组件是我们编写的组件，是应用程序或其他组件的依赖项。

引导程序包含框架代码的所有依赖项（在本例中为 aurelia 和 redux）。它是每个应用程序的 devDependency，但它是 shell 的依赖项。这允许开发人员在开发时独立运行应用程序（但不是在生产中，它总是从 shell 运行）。

目前，为了构建和发布东西，webpack 将 shell 中的所有内容捆绑到一个文件中，然后进行部署。一切都很好，一切正常，但这并不理想。

此项目中的每个应用程序都由不同的团队拥有。每个团队都有自己的发布周期，我们希望能够让他们在不影响其他人的情况下构建和部署自己的应用程序。理想的设置（捆绑后）是：

我们想要的是能够加载 shell 应用程序，并且只根据需要加载 app1/app2 js 文件。据我了解，我们需要使用脚本加载器来按需执行此操作，因为 webpack 不处理此用例，我对此很好。但我不知道的是，如何在没有引导程序代码的情况下构建每个单独的应用程序，并让它能够在运行时动态引入。

我们还希望应用程序在运行时可定位，而无需重新部署其他应用程序。如果我们添加一个 app3.hash.js，我们希望能够动态加载它。

我想不通的是如何以我们想要的方式捆绑应用程序。我得到的最接近的是使用 CommonsChunksPlugin，但这需要我们构建 shell。理想情况下，我们需要类似 DllPlugin 的工作原理，因此我们可以单独构建每个应用程序，但这需要从 shell 引用它的清单，这需要我们构建 shell。我们还尝试了 library 和 libraryTarget 和 externals 的组合，但没有成功。

有任何想法吗？谢谢！

我有一些服务以这种方式组织成一个 monorepo：

repo_root/ ├── services/ │ ├── service_one/ │ ├── service_two/ │ └── service_three/ ├── package.json ├── node_modules ├── .eslintrc

此外，每个单独的服务都有自己的package.json和node_modules. 我想使用存储在repo_root目录中的 eslint 配置来 lint 单个服务。我的问题是，当我尝试运行类似

eslint services/service_one

例如，找不到.目录下需要.eslintrc安装的 eslint 插件模块。node_modulesrepo_root

我想避免在每个服务中都需要这些插件模块。无论如何配置 eslint 以智能地查找模块，即使它们位于服务本身的父目录中？

我们有兴趣将 monorepo 迁移到 git，并希望将其与基于管道的 CI/CD 集成。

到目前为止，我们看到的一般模式是存储库根目录中的单个管道描述文件，这意味着每个存储库都有一个管道。这似乎是 Jenkins Pipeline、Gitlab、Bitbucket CI、CircleCI 等所遵循的模式。

给定一个 monorepo，我们想要多个这样的文件，一个用于 repo 中的每个项目。

是否有管道式 CI 可以做到这一点？

我们可以想到的另一种选择是为所有项目使用自定义过滤的管道描述文件。是否有任何现有的管道 CI 系统可以在没有额外工具的情况下处理这个问题？

这是一个问题。

我正在尝试将我的一些包合并到一个 monorepo 中。我正在使用yarn它的workspaces-experimental功能。因此存储库文件夹结构如下所示：

现在，目标之一是简化测试。我想jest在根目录中运行，以便它为所有包运行单元测试。它适用于myapp1及myapp2以上的 node.js 应用程序。但是，它是用（无弹出）myreactapp1构建的，并使用 ES6 特性（如）和 jsdom 渲染。如果我从dir运行它们，这些测试工作正常，代码通过管道（如果我理解得很好）。但是根笑话在第一条语句上失败了。create-react-appimportmyreactapp1yarn testbabelimport

我该怎么做 ？

PS我尝试安装babel-jest，但似乎无法直接从控制台（Windows）启动。

我有以下目录结构：

我已经使用lerna链接component-library到app.

此刻，我正在链接到component-library.

我想以某种方式监听组件库文件夹中的更改，这将导致重新编译。

我需要使用 gulp 吗？