My company currently has SVN as main version control and we are in process of migrating to Git. Doing that is a perfect chance to do a structure reorganization.
Before I get to that let me describe current situation and our use cases. We have one main product and 20-ish clients which have customizations in place. What that means is that if client A wants a module from project customized to his own needs, we would do that.
So currently we have a default version in place which has its own repository. Each client has its own repository separated from the default one. The logic is that a client repository through
composer.json shows on specific tagged default version. With some inner logic, overrides take precedence on client projects so that we don't touch the main project when it comes to customizations. SaaS is not a possibility, we need on premise installs.
Although this is the only way I currently see as a model which suits our needs, I find it rather cumbersome to have to maintain 20 repositories instead of one.
Solutions and why they don't work
- My initial idea was having a git submodules. This would however be absolutely the same with the current situation as I couldn't unify repositories
- Other idea was to have a single repository with
Clientsfolder, and then set Jenkins to grab a specific folder depending on what project is being built. This however fails because clients have strict requirements of when and how the updates will happen and we can't force it on them. This means that if clients have a
v1.0, we do have a contract to deliver fixes, but they are not obliged to go to
v2.0. So in this configuration, I can no longer target
v1.0if development went forward
- Last but not least, I had a plan of having Git flow set up where each branch would be a separate client...thus also having master, dev and feature branches for each client, meaning that one repo would have about
20*3=60branches minimum. While this is manageable with some strict rules, I have an issue here because if I have 20 clients on
v1.0and one of them notices a bug in version, I need to do a fix on master and then propagate that fix by hand to each branch. Even worse, if default master went on with development and is currently at
v2.0, introducing a quickfix would mean cherry picking commits and propagating it to other X branches.
Is there any other solution that would fit my model which I'm not seeing here?