Git 在不同的存储库中拆分一个大项目有多深？

我最近将Subversion存储库迁移到Git。一切顺利。我使用了git的理念，为软件的每个模块创建单独的存储库。但是现在开发人员告诉我，他们经常在主应用程序和其中一个模块中进行一些更改，这会进行两次提交，在一次提交中进行更改是有意义的。 这告诉我，模块并不是真正从主应用程序中分离出来的。因此，一个大型存储库是有意义的。 另一方面，我们的主要产品是开放源代码和一些模块，我们将这些存储库同步到Github和Sourceforge。但是也有一些封闭源代码的模块，它们真的不应该放在外面。因此，他们必须在我们内部的Gitlab中进行单独的回购

他们要求我创建两个大型（svn风格）存储库：一个用于开源，另一个用于封闭源代码。另一方面，我（QA&release management）觉得这与不同部分如何交互有关，与你如何在一个地方改变任何东西而不必在另一个地方改变其他东西有关。但我不是一名全职开发人员，我还没有深入挖掘这个特定代码库的深度

另一个论点是：该软件有Java和C风格。Java版本以前是在不同的Jenkins作业中从svn构建的，每个模块一个（因此从CI的角度来看，拆分git repo非常有意义），而C#版本是在一个大型TeamCity作业中构建的（借给一个大型svn风格的repo）

我知道git的一般做法是拆分，但是拆分的深度有多深？

这在很大程度上取决于您有多少个独立的模块，其中有多少个模块经常一起移动。在我们的团队中，我们有4个不同的java模块（独立运行）、一个C#代码库、一个perl模块库、DB人工制品和一套shell脚本

我们的代码库已经存在了4-5年，这导致了大量代码、提交和未使用的分支。尽管git速度很快，而且有很多大型回购的工程，但一段时间后，无论出于何种原因，风投（git/svn/）中存在如此多的瑕疵都是不健康的。此外，如果我们有独立的回购协议，那么当开发人员弄乱存储库（这种情况很少发生）而不影响其他回购协议时，合并和重置都会更容易

此外，我们的C#层和java API层之间也有类似的依赖关系，在这两个repo中有时都需要进行提交，但我们计算出，API或C#层中的单个提交数量远远超过协调提交，因此转向多个repo对我们来说是有意义的。这也有助于我们的所有模块都不是紧密耦合的，并且拥有健全的内部版本控制系统，帮助我们在微服务类型的体系结构中维护它们

---

您可以设置与技术相关的构建/测试/CI堆栈，而不管您是否有多个repo/单个repo，因此这不应该是您想要执行的决定因素

模块是否注册为git子模块？为什么开发人员说“只做一次承诺是有意义的”？2提交可以是和描述为一个git模块，保持主/模块代码彼此分离将使存储库历史更加整洁。另一方面，如果回购协议有很强的依赖性，合并可能不是一个坏主意。最后，我认为一个团队应该根据他们的需要调整工具，而不仅仅是为了它而坚持最佳实践。如果他们认为通过合并存储库，他们的工作流程将得到极大的改进，那么这可能是一条可行的道路。不，他们没有注册为git子模块。我必须弄清楚git子模块如何与git流工具结合使用。依赖关系仅在一个方向上，主应用程序可能没有任何模块。团队中的一些人认为，如果大多数提交仅针对一个模块，并且不改变主应用程序中的任何内容，那么拆分回购协议是有意义的。对于我们的最终用户也是一样，他们中的大多数只使用主应用程序。另一件事，在subversion中，其中一个模块在过去已经被拆分为sourceforge上的一个单独项目，并有一个单独的repo。由于历史原因，其他两个模块与主应用程序保留在同一回购协议中，但它们与已拆分的一个模块处于同一级别。是的，有点乱，我试着恢复一致性。子模块不适合我们的工作流程。另一方面，子树可能是更好的解决方案。我们可以在一个大型回购协议或单个小型回购协议中工作，我们甚至可以包括封闭源代码的内容，同时仍然保持与外部世界的隔离。核心和模块（几乎）总是一起发布，但我们仍然可以在开放源代码和封闭源代码之间进行划分。在我们的例子中，更容易的合并和重置是强有力的论据。我用git子树创建了一个组合存储库，乍一看，在核心和模块之间似乎有一些协调的提交，但大多数确实是单独的。但我们确实可以做更多的工作来减少紧耦合。这是一项持续不断的工作！：）对于开放源代码和封闭源代码，我相信一些公司通过github向公众开放他们的开放源代码。我特别建议将开放源代码保留在不同的repo中，这样，如果有人将其分叉并创建一个pull请求，您可以始终将其合并回您的repo中，而无需找出子模块和其他相关进程。这是一个非常好的逻辑分离