#Create submodule git how to#
#Create submodule git code#

Still, if you have a solid requirement to embed reused code right inside the container code, then you are left with a choice between submodules and subtrees. This will save you a world of pain (and you don’t necessarily have to publish your packages out in the open, these systems often allow for private packages too). Honestly, if you can manage your code dependencies by packaging reused code cleanly in “centralized” modules and using dependency management tools, do it. If the technological context allows for packaging and formal dependency management, you should absolutely go this route.Īs a reminder, here’s a list of the main languages and their dependency management / packaging systems and registries: Language

On the other hand, if the technological context allows for packaging and formal dependency management, you should absolutely go this route instead: it lets you better split your codebase, avoid a number of side effects and pitfalls that litter the submodule space, and let you benefit from versioning schemes such as semantic versioning ( semver) for your dependencies. In such a situation, going with submodules (or subtrees) probably is the right solution, provided you do need to version that code and collaborate around it with third parties (or deploy it on another machine) for strictly local, unversioned situations, symbolic links are probably enough, but this is not what this post is about. are often de facto installed by their mere presence at conventional locations inside the project tree, and this is the only way to “install” them. For instance, themes and plugins for Wordpress, Magento, etc. There are a number of situations where the physical presence of module code inside container code is mandated, usually because of the technology or framework being used. In the remainder of this text, I’ll call such reused code, present somewhere inside container repo trees, a “module.” As for project code that reuses said module somewhere inside its working directory’s tree, I’ll call that a “container.” Are they the right tool for the job? The goal is usually to benefit from central maintenance of the reused code across a number of container repos, without having to resort to clumsy, unreliable copy-pasting.

Submodules, like subtrees, aim to reuse code from another repo somewhere inside your own repo’s tree. In this post, we’ll dive deep into Git submodules, starting by making sure they’re the right tool for the job, then going through every standard use case, step by step, so as to illustrate best practices.

#Create submodule git how to#

Still, they are not without merits, if you know how to handle them. Submodules are hair-pulling for sure, what with their host of pitfalls and traps lurking around most use cases. If you used submodules before, you certainly got a few scars to show for it, probably swearing off the dang thing. Cette page est également disponible en français.