2

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.

geocodezip
  • 390
user8473264
  • 37

1 Answers1

3

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.

gntskn
  • 294