Git repository structure and modularity

2019-08-02 08:11发布

问题:

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.

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

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)
    ...

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.

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?

Thanks

回答1:

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.

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.

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.