It happens every now and then. You're working on a group of projects and realize that many of them are using some of the same codebase. So you decide to split things up into modules and seperate projects. This is simple when you are writing public code but more complicated when you want to keep your code in a private git repo. The obvious first step is to create a separate git repo so that you have one source of truth and all of your other projects can depend on that code base... but how do you manage that dependency in all of your projects (keeping in mind that if you intend for your modules to be private git repos, the solution isn't trivial)?
The research phase:
I did research and ultimately concluded that git submodules were just too complicated and would frustrate anyone who wanted to collaborate on the project. Ultimately, git submodules require too much buy-in. So what were the other options? There had to be something... but after a little bit of research I decided I'd write my own specifications and build my own library as a git submodules alternative.
What I wanted
So I specced out my requirements and came up with the following:
- The production environment shouldn't care what was used for dependency management.
- Everything should be done locally and be checked in to the git repo without bloat and without the
- There should be no extra setup time for someone who just wants to clone the dependency or the project using it.
- There should be an easy way to install specific branches or git commits.
- It should be easy to update the dependency but also easy to no longer use the dependency management tool and use a modified version of the dependency.
But then I realized... what I described was Bower.
Bower as an alternative to git submodules:
After speccing out my own library I realized that what I described was Bower and I ain't talking about 24. Technically bower is a package manager for the web but what's nice about it is that its light and that you can install any git repo. The language or technology being used is completely irrelevant. That's EXACTLY what I was looking for.
Install your package(s) in your project
bower install firstname.lastname@example.org:<username>/<reponame>.git
Update your package(s) in your project
Install a specific branch or commit (although discouraged)
bower install email@example.com:<username>/<reponame>.git#branch-or-commit-hash
Ultimately, this is a much simpler option than using git submodules. I'm not sure if there will be repercussions or drawbacks I haven't yet considered but for now, I like this solution a lot. It works and does exactly what I need. As always, I'm open to thoughts, critiques and the like.