一个大的Git仓库还是多个小的仓库？

Question

一个大的Git仓库还是多个小的仓库？

gittfstfvc

22

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

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

我倾向于使用一个单独的Git仓库，因为：

简化了团队的复杂度。
一个提交可以涉及几个解决方案的相关更改（例如从一个解决方案移动代码到另一个解决方案）。

另一方面，一个单独的Git仓库意味着对任何一个解决方案的更改都会导致我们的TeamCity CI服务器重新构建所有解决方案。

寻求其他团队领导在这个问题上的一些见解。

- user1147862

5个回答

4

对于开源项目，如果您想向全世界公开VCS访问，则应该为每个项目创建一个仓库。传统上，开源项目的许多惯例使用每个包所产生的仓库，但随着打包工具和相关惯例的改进以更好地支持多租户仓库，这种情况正在改变。

对于内部工作来说，单个仓库（或几个大型仓库）要优于多个仓库。否则很难确保需要交互或共享资源的代码库之间的一致性。在现实世界中，我在许多仓库的每种情况下都发现自己遇到了额外开销和同步问题，这是不必要的。

当然也有例外。对于彼此无关的事物，它们可以放在不同的仓库中。Git也存在一些单仓库的缺陷。如果你将其与SVN进行比较，你会发现单仓库非常好用（externals，不需要拉取整个仓库，可以获取特定的文件夹等）。您可以通过使用符号链接解决其中的一些问题。

- jgmjgm

同意99%。有一个小问题：我使用Git处理过非常大的代码库，没有出现任何问题。当时让我非常惊讶。诀窍是绝对不要提交任何二进制文件、依赖项或生成的文件。即使代码包含这些项目，您也可以清理源代码树并限制您使用Git拉取的版本深度。但是，即使有很多垃圾被检入（旧代码库、许多开发人员、没有好的C/C++依赖项管理器，这种情况会发生...），在初始克隆之后，1GB的存储库也是可以接受的。 - Charlie Reitzel

2

保持现有的方法论，每个解决方案一个仓库。如果需要，可以配置TeamCity仅基于某些仓库中的更改进行构建。我知道Jenkins可以做到这一点。

- Larry G. Wapnitsky

2

我建议将每个项目放在独立的存储库中，让构建服务器单独与它们交互。通过创建一个包含每个独立项目存储库的子模块的单一存储库，您仍然可以为开发人员简化事情并促进跨存储库的变更协调。因此，开发人员检查这个大存储库（通过子模块引用，将获取项目存储库），而构建服务器只需拉取项目存储库。

- Mark Adelsberger

2

如果你的团队没有太多子模块的经验，那么我建议不要采用这种方法。子模块在理论上很酷，但在实践中可能会造成混乱。 - zypherman

2

如果您没有与它们的经验，请不要尝试获取相关经验。如果您具有实际问题，我会很感兴趣听取您的意见，但这听起来就像是那些不想 - 或者不愿意 - 学习如何正确使用某个功能的人故意炒作的恐惧传言。 - Mark Adelsberger

1

@Mark Adelsberger，我不了解子模块的概念，但它是否提供了单一代码库的优势？主要包括：提交一致性：在任何子项目上进行相关更改的单个提交，而不是每个存储库的功能分支和主/默认分支之间的合并混乱。我快速浏览了官方文档，没有给我提供这些强大的单一代码库布局的优势的感觉。 - davidxxx

@davidxxx - 由于我强烈反对单一代码库，所以关于单一代码库的“优点”，可能不应该问我。 - Mark Adelsberger

@davidxxx 是的；包含子模块的存储库能够原子地从一个提交集（子模块的）切换到另一个，以便不同存储库中的相关更改保持在一起。 - TamaMcGlinn

1

我知道这是一个老问题，但我想把Git OPS、基础设施即代码的角度加入到混合中来。

当您使用高度参数化和模板化的IaC文件，依赖于基于约定的命名和替换时，每个功能都有一个Git仓库更加合理。

在单一仓库中，您需要大量自定义的IaC管道，可能不太标准化或可重用。

- Wim

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Philippe · Accepted Answer

即使在使用git时，普遍认为我们应该按项目使用1个仓库（大多数答案或建议都会告诉你这样做），但确实有将所有内容放在同一个仓库中的解决方案，这被称为“单一仓库”策略。

像谷歌、Facebook和微软这样的大型互联网公司正在使用它（不仅仅是git），而微软也正在朝着这个方向发展...所以你可以很容易地找到一些关于优缺点的文档。

例如：https://github.com/babel/babel/blob/4c371132ae7321f6d08567eab54a59049e07f246/doc/design/monorepo.md 一旦你明白其中一个主要问题是版本控制工具的性能（但git肯定可以支持一个5人开发团队），这更多是一个项目的感觉...因为看起来，你已经有了一些优势的想法，我强烈建议你去尝试一下！

此外，如果您对仓库的合并不满意，使用git命令拆分仓库（保留历史记录）要比合并仓库的命令简单得多，所以这似乎是首先尝试的方法。

在我的团队中，我们越来越倾向于使用单一仓库。

引用：我的团队由5名开发人员组成，负责维护一个中等规模的应用程序，包含6个解决方案（也称为部分）。

如果这是一个应用程序，单一仓库确实可能是一个好的解决方案。

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

要么您移除nuget的使用，使用二进制依赖（不要将其提交！），这样您就必须构建它们所有（但如果您想使用分支，这将很困难）。

要么您接受进行两次提交来进行更新（就像您在多个git仓库中所做的那样）。可以手动完成，也可以使用构建自动化。

附注：git子模块对于初次使用git的用户来说很困难，也不是很推荐的解决方案...所以基于此的解决方案可能会很痛苦 :-(

引用：另一方面，一个单一的Git仓库意味着对任何解决方案的更改都会导致我们的TeamCity CI服务器进行全面重建。

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

附注2：我给出了一个比预期更长的答案；-) 希望能对你有所帮助...