So git submodules aren’t really all that complicated, but because they’re wrapped in mystery and intrigue (much like rebase and reflog), they tend to be a bit less well understood.
As any long-time readers of this blog will immediately guess, I’m going to say that’s mostly because submodules are merely unfamiliar, rather than being complicated.
So while getting myself more familiar with some of the more simple functions of submodules, I thought I would create a very simple (extremely simple) micromaterial for adding a submodule to a local repository, and then updating it based on changes in the remote.
The high level overview of what we’re doing is as follows:
- we first fork and clone some very simple code that starts a webserver and sends back predicted awesomeness for the city you enter in the path (eg,
http://localhost:3001/chicago) - we then fork and clone another repository that contains the code we’re going to add as a submodule (this is a very simple function that takes a number input, modifies it and returns it). We fork this locally so we can update it and push it back to our remote fork. The remote fork is what the original code is going to track as a submodule.
- We add in the submodule to our original code, and we see how it is modifying the number that’s coming back.
- We now update the submodule code and push that back to our remote fork.
- Lastly, we use
git submodule update --remoteto update our main code to use the new version of the submodule.
And that’s it!
https://github.com/lpmi-13/submodz
I was kind of thinking of adding in other micromaterials for things that you can do with submodules, but I’m honestly not even sure what they are. Though if I can find something that actually seems like it might be useful to know, I’ll be sure to add a micromaterial and write it up here!
micro materials blog 