{"id":5312,"date":"2020-10-08T20:58:15","date_gmt":"2020-10-08T18:58:15","guid":{"rendered":"https:\/\/www.almtoolbox.com\/blog\/?p=5312"},"modified":"2022-02-28T14:30:46","modified_gmt":"2022-02-28T12:30:46","slug":"learn-about-git-submodules","status":"publish","type":"post","link":"https:\/\/www.almtoolbox.com\/blog\/learn-about-git-submodules\/","title":{"rendered":"Learn More About Git Submodules"},"content":{"rendered":"
Last update: 2\/27\/2022<\/em><\/h5>\n

In this article, we want to tell you how to control versions of complex systems using git submodules<\/strong><\/em>.
\n<\/span>Let’s have a look at the following imaginary example.\u00a0<\/span><\/p>\n

Our company has developed a system named Car, which consisted of 3 subsystems: Motor, Steering, and Transmission.<\/span><\/p>\n

\"vehicle<\/p>\n

Each subsystem has been developed in a separate Git repo and progressed from one version to another.\u00a0<\/span><\/p>\n

Up to a certain stage, each subsystem could be tested independently, but in the end, we needed to assemble and test the whole Car. <\/span><\/p>\n

How could we know with what version of each subsystem would we test it? Where would it be recorded?<\/span><\/p>\n

This is where git submodules<\/em> came to our help. We created a fourth repo, Car<\/em>, and included all three subsystem repos as submodules. <\/span><\/p>\n

We did not copy files to the Car repo. The Car repo contained only pointers<\/span> to specific commits of each of the three subsystem repos.<\/span><\/p>\n

To understand it better, let’s look at the following table:<\/span>\"table1\" On July 1, 2020, we created commit 1.0 in repository Car, which contained links to commit 1.1 in Motor, commit 1.3 in Steering and commit 1.4 in Transmission, so when we tested version 1.0 of Car, we knew exactly what version of each subsystem was used.\u00a0<\/span><\/p>\n

After two months…<\/h3>\n

Two months had passed, and version 2.0 was developed for each subsystem. However, we didn\u2019t want to test all changes at once. We decided to start with Transmission. Thus we created a new commit in Car, 1.1, which had version 2.0 of Transmission and no changes in other subsystems.<\/span><\/p>\n

After successfully testing Car with version 2.0 of Transmission, we created commit 1.2 in Car, with version 2.0 of Motor, and tested it. And lastly, we created and tested commit 2.0 of Car, with all subsystems at version 2.0.<\/span><\/p>\n

Using submodules for access control<\/h3>\n

If you are using a web-based Git server like GitLab, GitHub, Bitbucket or Azure DevOps, you can use submodules to control access to your software. In the above example, if Motor, Steering and Transmission are being developed by subcontractors, you can limit access of each subcontractor to its repository, and give full access to all repositories to Car integrators only.<\/span><\/p>\n

Conclusion<\/h3>\n

Using Git submodules, at each test of Car we knew what versions of subsystems were used. Moreover, since all commits were saved in the Car repo, now we can replay any of the previous tests exactly as they were run originally.<\/span><\/p>\n

Note: Those of you who have used or still are using ClearCase UCM may remember that it has similar functionality, named composite baseline<\/em>. It also allows you to manage projects comprising multiple repositories.<\/span><\/p>\n

We provide training of git, Advanced git, GitLab, GitLab CI, Bitbucket, GitHub, git + Kubernetes and software development workflows.
\nContact us for more information: git@almtoolbox.com<\/a> or call us +31 85 064 4633 (International) \/ 866-503-1471 (US & Canada)<\/div>\n
<\/h5>\n

Related Links:<\/h3>\n