Loading page
About this tool
Compare git submodules, git subtree and package dependencies for sharing code across repos, scored for your team and workflow.
This chooser scores the three standard ways to share code across git repositories — git submodules, git subtree and a published package dependency — against six facts about your situation: registry availability, change frequency, whether consumers edit the shared code, team git expertise, consumer count and exact-commit pinning. The trade-offs encoded come from the Pro Git submodules chapter, git's contrib/subtree documentation and standard registry practice, and every point scored is explained.
Open Git Submodule vs Subtree Chooser on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
Includes the package-registry route that submodule-vs-subtree debates usually forget.
Reasons cite the actual behaviours: pointer pinning, --recurse-submodules, subtree push, semver upgrades.
Each mechanism lists why it may hurt in your case, like vendored copies diverging across many consumers.
A submodule stores a pointer to an exact commit of another repository, checked out into a nested directory — the code is not in your repo. A subtree copies the other repository's files (and optionally history) into a subdirectory of your repo, so a plain git clone contains everything. Submodules pin precisely but demand submodule-aware workflows; subtrees are invisible to consumers but duplicate content.
Because the workflow has sharp edges the Pro Git book itself documents: cloning without --recurse-submodules (or running git submodule update --init) leaves empty directories, the submodule checks out a detached HEAD, and every update to the shared code needs a pointer-bump commit in each parent repo. Teams with strong git discipline handle this fine; mixed-experience teams frequently do not.
When it is a stable library with several consumers and a registry is available. Publishing versioned releases gives consumers semver upgrades, changelogs and lockfile pinning, and avoids both submodule pointer ceremony and subtree divergence. The cost is release overhead and a slower loop when a consumer needs to change the shared code itself.
Yes — git subtree push -P <prefix> <remote> <branch> re-splits the commits that touched the subtree directory and pushes them to the shared repository. It works, but it rewrites those commits and gets slow on big histories, which is why teams whose consumers edit shared code heavily sometimes still prefer submodules or a package workflow.