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

时间:2017-04-26 12:43:56

标签: git tfs tfvc

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

我想迁移到Git。我的问题是,对于所有6个解决方案是否有1个Git仓库,或者为每个解决方案使用单独的Git仓库。

我被一个单一的Git回购所吸引,因为:

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

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

在此问题上寻找其他团队负责人的一些见解。

4 个答案:

答案 0 :(得分:5)

即使使用git,它目前也承认按项目使用1个repo(并且大多数答案或建议会告诉你这样做),它们确实是将所有内容放在同一个存储库中的解决方案, 'monorepo'战略。

大型互联网公司正在这样做(不仅仅是git),谷歌,Facebook和微软(几乎)正在努力......所以你很容易找到一些关于赞成和反对的文档。

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

一旦你理解了主要问题之一就是你的版本控制工具的性能(但git肯定会支持5开发团队),这更像是一个项目感觉......看起来,你已经有了一些优势的想法,我强烈建议你去测试它!

此外,如果你不满意,拆分存储库(保留历史记录)的git命令要比合并存储库容易得多,所以它似乎首先尝试。

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

  

我的5个开发团队维护一个中等大小的应用程序,包含6个解决方案(又名部分)。

如果是一个应用程序,monorepo确实可能是一个很好的解决方案。

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

你要么删除使用nuget而你使用二进制依赖(没有签入!)所以你必须构建所有这些(但是如果你想使用分支则很难)。

您接受进行2次提交进行更新(就像您使用多个git存储库一样)。可以手动完成,也可以使用构建自动完成。

Ps:git子模块很难,并且对于第一次使用git的用户不太建议...所以基于这个的解决方案会很痛苦: - (

  

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

不一定,您可以为每个解决方案制作不同的构建版本,并仅在自己的解决方案文件夹上设置teamcity触发器。

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

答案 1 :(得分:1)

我会将每个项目保留在自己的仓库中,让构建服务器单独与它们进行交互。您仍然可以通过创建包含每个单独项目存储库作为子模块的单个存储库来简化开发人员的工作并促进跨存储库的更改协调。因此开发人员检查了大型仓库(通过子模块引用,将获取项目仓库),构建服务器只需拉动项目回购。

答案 2 :(得分:0)

保持目前的方法,每个解决方案只有一个回购。如果需要,请将TeamCity配置为仅基于某些存储库中的更改进行构建。我知道詹金斯可以做到这一点。

答案 3 :(得分:0)

对于开源,您希望向全世界公开VCS访问权限,那么每个项目都应该有一个存储库。

对于内部工作,单个存储库(或几个大型存储库)要优越得多。否则,要确保需要交互或共享资源的代码库之间的一致性是非常困难的。在现实世界中,在具有许多存储库的每种情况下,我发现自己在不必要地跨越其他存储库时会产生额外的开销和同步问题。

有一些警告。对于彼此无关的事情,他们可以愉快地在不同的存储库中。 Git在单回购方面也存在一定的不足。你会看到这个,如果你把它与SVN进行比较,其中monorepo工作得很好(外部,不需要拉整个回购,可以得到一个特定的文件夹等)。你可以解决其中的一些问题,例如使用符号链接。