git - 一个大的 Git 仓库或多个小的

Question

我的 5 名开发人员团队维护着一个由 6 个解决方案(也称为部分)组成的中型应用程序。目前，我们使用 TFVC 进行源代码控制。每个解决方案都位于自己的主分支中。

我想迁移到 Git。我的问题是，是为所有 6 个解决方案使用 1 个 Git 存储库，还是为每个解决方案使用单独的 Git 存储库。

我被一个单一的 Git 仓库所吸引，因为:

• 降低了团队的复杂性。
• 一个提交可以在多个解决方案中进行相关更改(例如将代码从一个解决方案移动到另一个解决方案)。

另一方面，一个 Git 存储库意味着对任何解决方案的更改都会导致在我们的 TeamCity CI 服务器上对所有解决方案进行全新的完全重建。

就此问题寻求其他团队领导的一些见解。

Answer 1

即使在使用 git 时，目前允许按项目使用 1 个存储库(并且大多数答案或建议会告诉您这样做)，确实有将所有内容放在同一个存储库中的解决方案，这称为'monorepo' 策略。

像谷歌、Facebook 和微软(几乎)那样，大型互联网玩家正在这样做(不仅是使用 git)......所以你可以很容易地找到一些关于利弊的文档。

例如:https://github.com/babel/babel/blob/4c371132ae7321f6d08567eab54a59049e07f246/doc/design/monorepo.md

一旦您了解主要问题之一是您的版本控制工具的性能(但 git 肯定可以支持 5 人开发团队)，它更像是一个项目的感觉......看起来，您已经了解了一些优势，我强烈建议您对其进行测试!

此外，如果您不满意，使用 git 命令拆分存储库(保留历史记录)比 merge 存储库要容易得多，所以它似乎是首先尝试的东西。

在我的团队中，我们越来越倾向于 monorepo。

My team of 5 devs maintains a medium sized application consisting of 6 solutions (aka sections).

如果这是针对一个应用程序，那么 monorepo 确实可能是好的解决方案。

但是您必须解决的一个问题是，如果您在使用 nuget 管理的解决方案之间存在依赖关系。

要么删除 nuget 的使用，要么使用二进制依赖项(不 checkin 它们!)，因此您必须构建所有这些依赖项(但如果您想使用分支将很困难)。

要么您接受进行 2 次提交以进行更新(就像您对多个 git 存储库所做的那样)。可以通过构建手动或自动完成。

Ps: git 子模块很困难，不建议第一次使用 git 的用户...所以基于它的解决方案会很痛苦 :-(

On the other hand, one single Git repo means that a change to any solution leads to a new complete rebuild of all solutions on our TeamCity CI server.

不一定，您可以为每个解决方案创建不同的构建，并仅在它们自己的解决方案文件夹上设置 teamcity 触发器。

Ps2:我做了比预期更长的答案 ;-) 我希望它会有所帮助...