{"id":225,"date":"2018-12-26T07:39:00","date_gmt":"2018-12-26T07:39:00","guid":{"rendered":""},"modified":"2019-07-03T13:05:01","modified_gmt":"2019-07-03T13:05:01","slug":"git-submodule","status":"publish","type":"post","link":"https:\/\/opstree.com\/blog\/2018\/12\/26\/git-submodule\/","title":{"rendered":"Git-Submodule"},"content":{"rendered":"
\n
\n
<\/a><\/div>\n

Rocket Science has always fascinated me, but one thing which totally blows my mind is the concept of modules aka. modular rockets. The literal definition of modules states<\/span> “A modular rocket<\/b> is a type of multistage rocket which features components that can be interchanged for specific mission requirements.<\/i>” In simple terms<\/span>, you can say that the Super Rocket <\/b>depends upon those<\/span> Submodules<\/b> to get the things done.
\nSimilarly is the case in the Software<\/span> world, where super projects have multiple dependencies on other objects. And if we talk about managing projects Git<\/b> can’t be ignored, Moreover Git has a concept of Submodules<\/b> which is slightly inspired by<\/span> the amazing rocket science of modules.<\/p>\n

Hour of Need<\/h3>\n

Being a DevOps<\/span> Specialist we need to do provisioning of the Infrastructure<\/span> of our clients which is sometimes common for most of the clients. We decided to Automate it, which a DevOps<\/span> is habitual of. Hence, Opstree Solutions initiated an Internal<\/span> project named OSM.<\/span><\/b> In<\/span> which we create Ansible Roles of different opensource software<\/span> with the contribution of each member of our organization<\/span>. So that those roles can be used in the provisioning<\/span> of the client’s infrastructure.
\nThis makes the client projects dependent on our OSM. <\/b>Which creates a problem statement to manage all dependencies which might get updated<\/span> over the period. And to do that there is a lot of copy paste, deleting the repository and cloning them again to get the updated version, which is itself a hair-pulling<\/span> task and obviously not the best<\/span> practice.
\nHere comes the git-submodule as a modular rocket<\/b> to take our Super Rocket <\/b>to its<\/span> destination<\/span>.<\/p>\n

Let’s Liftoff with Git-Submodules<\/h4>\n
“A submodule is a repository embedded inside another repository. The submodule has its own history; the repository it is embedded in is called a superproject<\/span>.<\/i>“<\/div>\n

In simple terms<\/span>, a submodule<\/b> is a git repository inside a Superproject’s git repository, which has its<\/span> own .git<\/b> folder which contains all the information that is necessary for your project in version control and all the information about commits, remote repository address etc. It is like an attached repository inside your<\/span> main repository, which can be used to reuse a code inside it as a “module<\/b>“.
\nLet’s get a practical use case of submodules.
\nWe have a client let’s call it “Armstrong” who needs few of our ansible roles of OSM for their provisioning of Infrastructure. Let’s have a look at their git repository below.<\/p>\n

$    cd provisioner\n$    ls -a\n     .  ..  ansible  .git  inventory  jenkins  playbooks  README.md  roles\n$    cd roles\n$    ls -a\n     apache  java   nginx  redis  tomcat<\/span><\/pre>\n
We can see in this Armstrong’s provisioner<\/i> repository(a git repository) depends upon five roles which are available in OSM’s repository to help Armstrong to provision their infrastructure. So we’ll add submodules osm_java<\/i> and others.<\/p>\n
$    cd java\n$    git submodule add -b armstrong git@gitlab.com:oosm\/osm_java.git osm_java\n     Cloning into '.\/provisioner\/roles\/java\/osm_java'...\n     remote: Enumerating objects: 23, done.\n     remote: Counting objects: 100% (23\/23), done.\n     remote: Compressing objects: 100% (17\/17), done.\n     remote: Total 23 (delta 3), reused 0 (delta 0)\n     Receiving objects: 100% (23\/23), done.\n     Resolving deltas: 100% (3\/3), done.<\/span><\/pre>\n
With the above command<\/span>, we are adding a submodule named osm_java whose URL<\/span> is git@gitlab.com:oosm\/osm_java.git<\/i> and branch is armstrong<\/span>. The name of the branch is coined armstrong<\/span> because to keep the configuration of each of our client’s requirement isolated, we created individual branches of OSM’s repositories on the basis of client name.
\nNow if take a look at our superproject<\/span> provisioner we can see a file named .gitmodules which has the information regarding the submodules.<\/p>\n
$    cd provisioner\n$    ls -a\n     .  ..  ansible  .git  .gitmodules  inventory  jenkins  playbooks  README.md  roles\n$    cat .gitmodules\n     [submodule \"roles\/java\/osm_java\"]\n     path = roles\/java\/osm_java\n     url = git@gitlab.com:oosm\/osm_java.git\n     branch = armstrong<\/span><\/pre>\n
Here you can clearly see that a submodule osm_java<\/i> has been attached to the superproject provisioner<\/i>.<\/p>\n
What if there was no submodule?<\/h4>\n
If that was a case, then we need to clone the repository from osm and paste it to the provisioner then add & commit it to the provisioner phew….. that would also have worked.
\nBut what if there is some update has been made in the osm_java which have to be used in provisioner<\/i>, we can not easily sync with the OSM. We would need to delete osm_java<\/i>, again clone, copy, and paste in the provisioner which sounds clumsy and not a best way to automate the process.
\nBeing a osm_java as a submodule we can easily update that this dependency without messing up the things.<\/p>\n
$    git submodule status\n     -d3bf24ff3335d8095e1f6a82b0a0a78a5baa5fda roles\/java\/osm_java\n$    git submodule update --remote\n     remote: Enumerating objects: 3, done.\n     remote: Counting objects: 100% (3\/3), done.\n     remote: Total 2 (delta 0), reused 2 (delta 0), pack-reused 0\n     Unpacking objects: 100% (2\/2), done.\n     From <\/span>git@gitlab.com:oosm\/osm_java.git<\/span>     0564d78..04ca88b  armstrong     -> origin\/armstrong\n     Submodule path 'roles\/java\/osm_java': checked out '04ca88b1561237854f3eb361260c07824c453086'<\/span><\/pre>\n
By using the above update command we have successfully<\/span> updated the submodule which actually pulled the changes from OSM’s origin armstrong<\/i> branch.<\/p>\n
What have we learned? <\/h4>\n
In this blog post<\/span><\/span>, we learned to make use of git-submodules to keep our dependent repositories updated with our super project<\/span>, and not getting our hands dirty with gullible copy and paste.<\/div>\n
Kick-off those practices which might ruin the fun, sit back and enjoy the automation.<\/div>\n
Referred links: <\/b>
\nImage: google.com<\/a>
\nDocumentation: https:\/\/git-scm.com\/docs\/gitsubmodules<\/a><\/p>\n<\/div>\n<\/div>\n
<\/p>\n
<\/div>\n
<\/div>\n

\n<\/p>\n
<\/div>\n
<\/p>\n
<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Rocket Science has always fascinated me, but one thing which totally blows my mind is the concept of modules aka. modular rockets. The literal definition of modules states “A modular rocket is a type of multistage rocket which features components that can be interchanged for specific mission requirements.” In simple terms, you can say that … Continue reading “Git-Submodule”<\/span><\/a><\/p>\n","protected":false},"author":159458168,"featured_media":29900,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[1],"tags":[768739308,768739295,15148152],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/opstree.com\/blog\/wp-content\/uploads\/2025\/11\/DevSecOps-1.jpg","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/pfDBOm-3D","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/225"}],"collection":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/users\/159458168"}],"replies":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/comments?post=225"}],"version-history":[{"count":3,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/225\/revisions"}],"predecessor-version":[{"id":1506,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/posts\/225\/revisions\/1506"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/media\/29900"}],"wp:attachment":[{"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/media?parent=225"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/categories?post=225"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/opstree.com\/blog\/wp-json\/wp\/v2\/tags?post=225"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}