Git子树 vs 代码库管理大杂烩

Question

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

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

- CommonLib1 - CommonLib2 - ApplicationA（使用CommonLib1） - ApplicationB（使用CommonLib1和CommonLib2）

虽然CommonLib1/CommonLib2是完全独立的，但几乎每个针对ApplicationA/ApplicationB的新功能都需要修改CommonLib1/CommonLib2。

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

据我所知，我只剩下两个主要选项：

1. 为每个项目创建一个仓库，并将CommonLib1/CommonLib2作为子树添加到ApplicationA/ApplicationB中。 2. 为所有项目创建单一的Monorepo。

对于我的情况，哪种是最佳的Git实践？

- Michael

---

Google在巨大的单体库上取得了成功。我建议从那里开始，尝试分解紧密耦合的项目。 - jaredready

我相信它会起作用，但我正在寻找最佳实践.. 我更喜欢从正确的方式开始。 - Michael

现在"monorepo"是真的存在吗？我在谷歌上搜索到了很多结果（https://www.google.com/#q=monorepo），但它们都只是在谈论"把一堆垃圾倒进一个大仓库"，这并不是真正的*东西*。StackOverflow上现在有这个标签，但标签特定信息里面几乎没有任何内容：http://stackoverflow.com/tags/monorepo/info - torek

可能是使用子树或子模块管理外部资源的Git的重复问题。 - Pockets

另外，你不应该仅仅因为 Google 这样做了就去效仿他们 - 他们实际上分叉了他们使用的 DVCS 软件，并推出了自己的版本，因为公开可用的工具不适合他们的工作流程。 - Pockets

Answer 1

CommonLib1/CommonLib2与ApplicationA/ApplicationB密切相关，因此建议您选择选项2（为所有项目创建单个Monorepo）。分支结构如下：

• Lib1分支：在此分支中管理/开发/更新CommonLib1。当它更新后，您可以将其合并到appA和appB分支中。

• Lib2分支：在此分支中管理/开发/更新CommonLib2。当它更新后，您可以将其合并到appB分支中。

• appA分支：管理/开发ApplicationA项目。

• appB分支：管理/开发ApplicationB项目。

- Marina Liu