I am currently working on a project comprising multiple sub-projects. Each sub-project, in turn, consists of multiple components, which might be shared by two or more sub-projects.

Let's say, for example, that there are the following components:

  • component A
  • component B
  • component C
  • component D

Each component has its own git repository and carries out a very well-defined task.

Then, there are the following sub-projects:

  • sub-project A, consisting of components A, B and C
  • sub-project B, consisting of components A, B and D

Sub-projects are independent from one another but, like in this example, can share components with other sub-projects. Also, both components and sub-projects will have their own versions (eg. sub-project A v1.5 comprises component A v2.3, component B v1.6 and component C v1.9).

Now the question is, what would be the best way to manage this scenario using git as version-control system? I thought that I could add the components to the sub-projects' repositories as submodules, but, having read that the use of submodules in git is usually discouraged, I wondered if there were better ways to accomplish the goal.

Edit: my question differs from this one because the latter appears very specific to Vagrant, a software that I do not plan to use.

  • What are the "components"? Are they code modules? If so they should probably be in their own repositories and independently published to a package repository for the projects to import.
    – Ant P
    Commented Aug 9, 2019 at 11:45
  • @AntP components in my case are independent applications that could theoretically work alone. Commented Aug 9, 2019 at 11:55
  • What are the contents of those sub-project git repositories? Repositories contain code, but if the components are basically stand-alone applications that are used as such in the sub-projects, they would not actually be contained in their repositories. So the sub-module repositories would just contain the glue that serves to make the applications work in concert, plus run-time dependency information to designate required component versions. If the components would be linked as libraries, you'd have build-time dependencies instead, but still the repositories stay separate. Commented Aug 9, 2019 at 13:43
  • @Hans-MartinMosner the sub-projects' repositories would contain at most some configuration files besides the submodules. I am unclear as to what you are saying; maybe because you mistook "sub-module" for "sub-project"? Commented Aug 9, 2019 at 17:23

1 Answer 1


Git is typically not considered an ideal tool for managing interdependencies; NPM, Maven, PIP and so on are typically much easier for developers and users to work with, depending on the situation and language involved.

That said, for projects where developers need to update the code of dependencies as often as they update the primary code, submodules and sub trees are often helpful.

Submodules let you include a link to one Git repo inside another, so that you can populate the whole dependency graph at once. It is not always easy to use, however.

Subtrees let you combine multiple repos together directly. I have found it easy for cases where two projects are so interdependent that the practically act as one repo already, or where duplication of code in the repo is necessary (eg for compliance reasons.) I find that they are easy to work with, but too heavy handed for most dependencies.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.