Back to list
The Internet is full of articles on why you shouldn’t use Git submodules. While submodules are useful for a few use cases, they do have several drawbacks.
Git flow works on OSX, Linux and Windows. OSX Homebrew: $ brew install git-flow-avh OSX Macports: $ port install git-flow Linux (Debian-based). 🙃 A delightful community-driven (with 1800+ contributors) framework for managing your zsh configuration. Includes nearly 300 optional plugins (rails, git, OSX, hub, docker, homebrew, node, php, python, etc), over 140 themes to spice up your morning, and an auto-update tool so that makes it easy to keep up with the latest updates from the community. ohmyzsh/ohmyzsh. Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. By data scientists, for data scientists ANACONDA. We made Newton Mail. We solve problems in the productivity space through Sensible Design and Cutting Edge Tech. Git subtree lets you nest one repository inside another as a sub-directory. It is one of several ways Git projects can manage project dependencies. Why you may want to consider git subtree. Management of a simple workflow is easy. Older version of Git are supported (even older than v1.5.2).
Are there alternatives? The answer is: yes! There are (at least) two tools that can help track the history of software dependencies in your project while allowing you to keep using Git:
git subtree- Google repo
In this post we will look at git subtree and show why it is an improvement – albeit not perfect – over git submodule.
What is git subtree, and why should I use it?
git subtree lets you nest one repository inside another as a sub-directory. It is one of several ways Git projects can manage project dependencies.
Why you may want to consider git subtree
- Management of a simple workflow is easy.
- Older version of Git are supported (even older than v1.5.2).
- The sub-project’s code is available right after the clone of the super project is done.
git subtreedoes not require users of your repository to learn anything new. They can ignore the fact that you are usinggit subtreeto manage dependencies.git subtreedoes not add new metadata files like git submodule does (i.e., .gitmodule).- Contents of the module can be modified without having a separate repository copy of the dependency somewhere else.
Drawbacks (but in our opinion they're largely acceptable):
- You must learn about a new merge strategy (i.e.
git subtree). - Contributing code back upstream for the sub-projects is slightly more complicated.
- The responsibility of not mixing super and sub-project code in commits lies with you.
How to use git subtree
git subtree is available in stock version of Git since May 2012 – v1.7.11 and above. The version installed by homebrew on OSX already has subtree properly wired, but on some platforms you might need to follow the installation instructions.
Here is a canonical example of tracking a vim plug-in using git subtree.
The quick and dirty way without remote tracking
If you just want a couple of one-liners to cut and paste, read this paragraph. First add git subtree at a specified prefix folder:
(The common practice is to not store the entire history of the subproject in your main repository, but If you want to preserve it just omit the –squash flag.)
The above command produces this output:
As you can see this records a merge commit by squashing the whole history of the vim-surround repository into a single one:
If after a while you want to update the code of the plugin from the upstream repository you can just do a git subtree pull:
This is very quick and painless, but the commands are slightly lengthy and hard to remember. We can make the commands shorter by adding the sub-project as a remote.
Adding the sub-project as a remote
Adding the subtree as a remote allows us to refer to it in shorter form:
Now we can add the subtree (as before), but now we can refer to the remote in short form:
The command to update the sub-project at a later date becomes:
Contributing back upstream
We can freely commit our fixes to the sub-project in our local working directory now. When it’s time to contribute back to the upstream project, we need to fork the project and add it as another remote:
Now we can use the subtree push command like the following:
After this we’re ready and we can open a pull-request to the maintainer of the package.
Can I do this without using the git subtree command?
Yes! Yes you can. git subtree is different from the subtree merge strategy. You can still use the merge strategy even if for some reason git subtree is not available. Here is how you would go about it.
Add the dependency as a simple git remote:
Before reading the contents of the dependency into the repository, it’s important to record a merge so that we can track the entire tree history of the plug-in up to this point:
Which outputs:
We then read the content of the latest tree-object into the plugin repository into our working directory ready to be committed:
Git Osx Install
Now we can commit (and it will be a merge commit that will preserve the history of the tree we read):
When we want to update the project we can now pull using the git subtree merge strategy:
Git subtree is a great alternative
After having used git submodules for a while, you'll see git subtree solves lots of the problems with git submodule. As usual, with all things Git, there is a learning curve to make the most of the feature.
Follow me on Twitter @durdn for more things and stuff about Git. And check out Atlassian Bitbucket if you’re looking for a good tool to manage your Git repos.
Git Osxkeychain
Update: After publishing this piece, I also wrote an article on the power of Git subtree.