Git setup for a collection of apps sharing volatile code

We have 7 apps (websites) all sharing a common submodule.

website1.git
website2.git
...
shared_engine.git

I think the submodule concept of tracking a commit rather than HEAD is great. Nice and predicatable... great for deployment. But, for development.. here be dragons!

If our submodules are pretty static eg. an xml library here, a timezone library there, they are perfect.

If however, we edit them a lot, they can become a pain! And in the above example, 95% of our edits are in the shared_engine! I believe they are a pain for 2 reasons…

1. When developing you want to be able to see your changes locally throughout all the apps without having to commit, push and pull. I achieve this by creating symlinks (which of course need reverted come commit time).
2. Doing any kind of branching requires a fair bit of admin as all the websites and shared submodule require the branch and linking them together.

Currently, I've written a collection of bash scripts that makes the symlinks for me and does some of the branching admin. They are a blessing but can get messed up.. I can't help feeling there is a better way!

I am badly tempted just to make one big repo out of them.

The website repos are ~3MB and the shared_engine is ~30MB. It would make life easier.. but there is a good chance more websites could come along. What then?

I thought this might be a common problem开发者_如何学运维… if you're in similar situation how are you dealing with it? Please save me from the monolithic repo!

cheers -H

An intermediate solution would be to use, during development, gitslave.

You would keep submodules declared in a parent repo used for integration / deployment.
But for the day-to-day development, gitslave would allow you to keep a set of repo in sync, especially when branching.