Git存储库结构和模块化 [英] Git repository structure and modularity

问题描述

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

The team I worked with decided to move away from svn towards git, which is a good thing I believe. I'm in charge of the migration and to re-structure the current svn layout.

svn 当前的内容如下所示：

What we currently have in svn looks like this :

/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时，我发现首选模块化方法。所以我想出了这样的结构：

When doing some research about git, I found out that a modular approach was preferred. So I came up with this structure :

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

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

However, I think this kind of breaks the modularity and the point of having different libraries IF they depend on each other (libB needs libA, libD needs libA and libC). You need to leave the scope of libB to add libA as a dependency.

然后我应该在每个库中添加一个 dependencies文件夹并将其作为子模块添加到其中，还是应该保留初始git布局？

Then should I add a "dependencies" folder to every libs and add them as submodule in there or should I keep the initial git layout?

这里首选的方法是什么？

What is the preferred approach here?

谢谢

推荐答案

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

More reliable approach is to have independent project lifecycle for each module. Also, when you release a library, you should maintain version number. The dependency should tell which module and which version of library, e.g. libB:1.0.0 needs libA:1.2.5, libD:3.4.5 needs libA:1.3.7 and libC:5.3.9. There are dependency management systems, e.g. maven in java world, deb in linux distributives, nuget in c#. They allow to track exact versions and see conflicts in version numbers, e.g. if you have a myApp:6.2.5 which needs libB:1.0.0 and libD:3.4.5 it means that the myApp depends on two different (potentially incompatible) versions of libA - 1.2.5 and 1.3.7.

当您拥有一台Continious Integration服务器时，它将构建已更改的模块并重建依赖关系，并运行测试以非常迅速地查找兼容性问题。

When you could have a Continious Integration server which will build changed modules and rebuild dependencies and run tests to hunt down compatibility issues very fast.

换句话说，版本依赖管理不是git或svn之类的版本控制系统的任务，最好使用特殊工具。但是，您可以使用git子模块或svn-externals来处理它，但效果不是很好。

In other words, the version dependency management is not task for version control system such as git or svn, better to use special tools. However you could use the git submodules or svn-externals to handle it, but it doesn't work very well.

这篇关于Git存储库结构和模块化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！