Maintaining project with plugins in git

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 in开发者_开发问答dividually)

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:

• each plugin in its own repository
• one parent project which would declare all the relevant plugins as submodules.

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.

---

So when I check the parent project out and remember to call "git submodule init" for each plugin, I would have all projects on my desktop.

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.

However submodules are pinned to versions, wouldn't this cause some more complicated workflow?

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:

• work in that component (working from that specific version *as a starting point")
• commit
• push that one component to its remote repo
• go up one level, back in the parent project
• commit the parent project (in order to reference the new version of the submodule you just modified)

Again, true nature of submodules details that process.