We are currently using SVN to develop an internal application that has most of its functionality in plugins. In our approach to switch git, this app is causing some headaches as to what the best practice is regarding handling this kind of project in git.
I.e. should we put every plugin into its own git repository? This would seem a logical choice as the plugins are mostly not depending on each other and rather stand-alone (just using the core app for framework functionality and management of common functions), often developed by different persons and occasionally deprecated. However there are now well over a dozen plugins with more to come and building the whole project would usually require checking out all (or most) of the plugins one by one. And there does not seem to be an easy way to check out ALL of them at once, i.e. there probably needs to be some kind of “list” out there so people know what to get and what not.
On the other hand, putting everything in one git repository seems to be not in the spirit of git, esp. as we would carry around old dead code and working on just one plugin would require checking out a lot of code (though then most developers working on it would check out everything anyway). Also branching would always branch everything (which makes for example cross-testing of branched features difficult if the plugins can’t branch individually)
One idea is to use submodules, but I don’t know whether the overhead (mental overhead, I mean) is bigger than the gain (or, whether we gain less than we lose with using the one-for-all approach).
How would/do you handle this kind of project in git?
This kind of system (as in “collection of writable components”) would be best managed with:
As detailed in “true nature of submodules“, you can then modify any plugin directly from that one parent project.
(See also Duplicate submodules with Git if you have duplicate dependencies)
And recent Git releases comes with commands able to recursively checkout all the submodules of a parent project.
But you shouldn’t have to remember to do anything beside
git submodule update --init --recursive(just one command). As I said, it will recursively initialize all your submodules.The principle of dependency management is to always reference a specific version (as opposed to reference “the latest code out there” for one component).
But that doesn’t prevent you to:
Again, true nature of submodules details that process.