Git Submodules as Dependency Management

Git can be used for managing dependencies. It some cases it is the best solution and has to be considered as a viable tool.

C++ does not have package management system and thus git submodules are a natural model to add any library dependencies. This results in highly cohesive approach to dependency management.

Many languages these days provide “packages”:

However, in a mixed solution environment it can be time consuming to maintain all custom package repositories. This results in need to learn yet another system. In case of NodeJS and .NET it means setting up 2 private package repositories and maintaining those.

Git submodules don’t replace the need to use public package repositories. It simplifies management of internal project dependencies for private repositories. It makes it more consistent and requires to learn only ‘git submodules’ model.

Pros:

Cons:

Recursive Nesting of Dependencies vs. Flat model

Git submodules support recursion. Thus a submodule can include other submodules and so on. While theoretically that looks like a perfect dependency management, in practice it is a not a good solution. NPM users learned it the hard way.

Thus, the recommended approach is a flat model.

The following is an example setup.

The advantage of the flat model structure is that all shared projects and all application projects can depend on shared projects and use relative paths to resolve these project. Thus, when writing shared projects we simply need to add all projects application depends on to the same level.

PROS:

CONS:

Complex dependency graph issue mitigation. The best way to mitigate the issue is to treat project from top level project perspective and not from individual subproject perspective. This means to apply single repository mentality. Subproject purpose in life is to be part of the top level application. If subproject has changed, all dependent projects need to change as well for top level application to stay in cohesive state. If the rule is not followed, then we have to have more than one version of the same subproject used at the same time (applies to git submodules and packages management systems).

NO Change:

Quick Start for Working with Submodules

Add Repository as Submodule

git submodule add -b MasterBranchName https://hostname/project.git projDirName

The command above will

Checking out of Project with Submodules

‘Git Extensions for Windows’ checks out git projects with submodules by default.

Checking in submodule changes

Check-in process is now a 2 step process:

  1. check-in submodule
  2. check-in owner of submodule

Checking out specific branch

Because git tracks submodules, checking out specific branch also means checkout of exact versions of submodules that branch depends on.