What is an effective git process for managing our central code library?
- by Mathew Byrne
Quick background: we're a small web agency (3-6 developers at any one time) developing small to medium sized Symfony 1.4 sites. We've used git for a year now, but most of our developers have preferred Subversion and aren't used to a distributed model.
For the past 6 months we've put a lot of development time into a central Symfony plugin that powers our custom CMS. This plugin includes a number of features, helpers, base classes etc. that we use to build custom functionality. This plugin is stored in git, but branches wildly as the plugin is used in various products and is pulled from/pushed to constantly. The repository is usually used as a submodule within a major project.
The problems we're starting to see now are a large number of Merge conflicts and backwards incompatible changes brought into the repository by developers adding custom functionality in the context of their own project.
I've read Vincent Driessen's excellent git branching model and successfully used it for projects in the past, but it doesn't seem to quite apply well to our particular situation; we have a number of projects concurrently using the same core plugin while developing new features for it.
What we need is a strategy that provides the following:
A methodology for developing major features within the code repository.
A way of migrating those features into other projects.
A way of versioning the core repository, and of tracking which version each major project uses.
A plan for migrating bug fixes back to older versions.
A cleaner history that's easier to see where changes have come from.
Any suggestions or discussion would be greatly appreciated.
