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. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |