Question

我工作的团队决定从svn转向git，这是一件好事，我相信。我负责迁移并重新构建当前的svn布局。

我们目前在 svn 中的内容如下所示：

/externals  (external libs copyed there like cunit, etc.)
/include    (public headers only)
    /libA
    /libB
    /libC
/source     (source and private headers)
    /libA
    /libB
    /libC
/tests      (tests projects)
    /libA
    /libB
    /libC

在对git进行一些研究时，我发现首选模块化方法。所以我想出了这个结构：

/externals      (repo externals.git)
/libA           (repo libA.git)
   /include
   /source
   /tests
/libB           (repo libB.git)
    ...

但是，我认为这种方式打破了模块化，并且让不同的库 IF 相互依赖（libB需要libA，libD需要libA和libC）。您需要保留libB的范围以将libA添加为依赖项。

那么我应该在每个库中添加一个“dependencies”文件夹并将它们作为子模块添加到那里，还是应该保留最初的git布局？

这里的首选方法是什么？

由于

Answer 1

更可靠的方法是为每个模块提供独立的项目生命周期。此外，当您发布库时，您应该保留版本号。依赖性应该告诉哪个模块和哪个版本的库，例如libB：1.0.0需要libA：1.2.5，libD：3.4.5需要libA：1.3.7和libC：5.3.9。存在依赖性管理系统，例如， java世界中的maven，Linux发行版中的deb，c＃中的nuget。它们允许跟踪确切版本并查看版本号中的冲突，例如如果你有一个myApp：6.2.5需要libB：1.0.0和libD：3.4.5这意味着myApp依赖于两个不同的（可能不兼容的）libA版本 - 1.2.5和1.3.7。

如果你有一个Continious Integration服务器，它可以构建更改的模块并重建依赖关系并运行测试来快速查找兼容性问题。

换句话说，版本依赖关系管理不是版本控制系统的任务，例如git或svn，更好地使用特殊工具。但是你可以使用git子模块或svn-externals来处理它，但它不能很好地工作。

Git存储库结构和模块化

1 个答案: