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

Question

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

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

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

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

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

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

Answer 1

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

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

例如: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:我做了一个更长的答案,预期;-)我希望它会有所帮助......