我最近将Subversion存储库迁移到了Git。一切顺利。我使用git哲学为软件的每个模块制作单独的存储库。但是现在开发人员告诉我，他们经常做的工作会改变主应用程序和其中一个模块的内容，这会产生两个提交，在一次提交中执行它是有意义的。 这告诉我模块与主应用程序并没有真正分开。所以一个大的存储库是有意义的。 另一方面，我们的主要产品是开源和一些模块，我们将这些存储库同步到Github和Sourceforge。但也有一些封闭的源模块，真的不应该出去。所以他们必须在我们的内部Gitlab中单独的回购。
他们要我制作两个大型（svn风格）存储库：一个用于开源，一个用于封闭源。另一方面，我（质量保证和发布管理）感觉它与不同部分如何相互作用以及如何在一个地方不能改变任何东西而不必在其他地方改变其他东西有关。但我不是一名全职开发人员，而且我还没有深入研究这个特定代码库的深度。
另一个论点：该软件存在于Java和C＃flavor中。 Java版本以前是从svn在不同的Jenkins作业中构建的，每个模块一个（所以从CI的角度看，拆分git repos非常有意义），而C＃版本是在一个大的TeamCity工作中构建的（借给一个大的， svn-style repo）。
我知道一般的git练习是将事情分开，但你有多深的分裂？
答案 0 :(得分：1)
对于有多少独立模块，它们中有多少经常一起移动，这取决于“很多”。在我们的团队中，我们有4个不同的java模块（独立移动），C＃代码库，perl模块库，DB工件和一套shell脚本。
我们的代码库已经存在了4到5年，这导致了很多代码，提交和未使用的分支。即使git很快并且有很多工程用于大型回购，但经过一段时间后，无论出于何种原因，在VCS（git / svn /）中都有这么多错误是不健康的。此外，如果我们有独立的存储库，那么只要开发人员搞砸了存储库（它不经常发生）而不影响其他存储库，就会更容易合并并重置 -
此外，我们在C＃和java API层之间存在类似的依赖关系，其中有时需要在两个repos中进行提交，但我们计算出API或C＃层中的单个提交数量远远超过协调提交，因此进入多个回购对我们来说是有意义的。它还有助于我们所有的模块都没有紧密耦合，并且拥有理智的内部版本控制系统，可以帮助我们将它们置于微服务类型的架构中。
您可以设置与技术相关的构建/测试/ CI堆栈，无论您是否有多个回购/单个回购，因此这不应该是您想要做的决定因素