I've been reading about the advantages of monorepos, but haven't yet found a mitigation for the problem of sharing parts of a repo:
Let's say an organization has a monorepo for a client/server web application. They hire a contractor to work on the design of some part of the client. How can they give the contractor access to only the relevant client code? Even sparse checkouts are not trivial.
git subtree
.With git subtree
you will be able to:
create a monorepo composed of subtrees, each of which can be linked to separate remote repos.
Given your example use case, the contractor would be given access to only the remote repo tied to a single subtree of the monorepo.
have a single aggregate/unified history (the point of a monorepo)
pull changes from subtree remotes into the monorepo
push changes made in any subtree of the monorepo to its separate remote
keep your simple/easy workfows.
git subtree
does not require users of your repository to learn anything new. They can ignore the fact that you are usinggit subtree
to manage dependencies."
For a list of pros/cons check out Atlassian's Git subtree: the alternative to Git submodule. Though I think the example steps in this article are rather limited if not outdated.
For step by step demonstrations with git log
details at each step:
The example and steps in Merging multiple repositories into a monorepo, while preserving history, using git subtree
are cleaner and more logical than the Atlassian article.
git subtrees: a tutorial also includes step by step actions and results for making changes in the monorepo and pushing to the subtree repo, and vice versa, and gives some good tips. It does mention one caveat, and that is rebases that include subtree pulls don't work. Another post explains,
Do not be tempted to rebase this. Push it as is. If you rebase, git subtree won’t be able to reconcile the commits when you do your next subtree pull.
If you must do a rebase, the follow up Atlassian article I link below provides a workaround.
I usually hate watching videos but Introduction to Git Subtrees one looks worth it and has lots of detail. Also it is far more recent (2019) than all the other articles. It's comforting to see in advance what you'll be dealing with.
If you want an under the covers understanding:
git subtree
and the git subtree merge strategy (git merge -s subtree
). In essence former uses the latter under the covers. In other words git's notion of porcelain vs plumbing.git subtree
came about, and how it works internally, as well as how subtrees are better than submodules, see Git: submodules vs. subtrees.monorepo-operator is a tool that may make managing your subtree-based monorepo easier. I haven't used it and cannot vouch for it, but might be worth checking out.