Git – Source control with multiple customer-specific repositories

branchinggitrepositoryversion control

Here is a diagram of how our source control setup is configured.

The issue with this setup is how we handle various customers. I would really like to use a different approach than copying the entire baseline for each of our customers. I think further down the road this will become a major problem to maintain.

How can this be best achieved? Any help insight would be greatly appreciated.

Best Answer

Some options:

Put only the customisations in separate repos and just copy them over the original repo when building the deployable. This is only feasible for superficial differences such as theming; once you have code patches in there it very quickly gets unmanageable.
Develop separately and merge changes which should be in both repos. This might seem like a good alternative until you have changes which you need to pull apart manually, line by line, to ensure that the repos each do what they want. This work just gets worse and worse with every merge, until inevitably the merges are too expensive to continue. Now everything is duplicate effort.
Make the customisations configurable, and put only the configuration in separate repos. This makes it much easier to handle code differences, since they are just feature toggles. The overhead of the switches is much more manageable than the other options unless they go completely out of control (and even then it's generally easier to just prune toggles than to do manual merges forever).

Related Solutions

Version Control – Creating a Version Control Strategy for SVN

If you want a unified build process, then be sure to put branches/tags/trunk at the root, like this:

branches/
tags/
trunk/
  dev/
    ...

If you don't need a unified build process, then you can put branches/tags/trunks within each project if you want. However, it might be difficult to migrate to a unified build after having put them within each project. A unified build has advantages, such as eliminating the need to publish shared components among projects -- they're all part of the build.

Personally, I like a unified build process. Furthermore, I don't think you should have a "dev" project. You should have projects directly under trunk, and then branch trunk into a dev branch. Use tags for releases. For example, I would do it like this:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

Git – an effective git process for managing our central code library

I feel your pain as I deal with this sort of thing every day. My situation is having to maintain multiple customer versions of an open source project, each with a different selection of plugins, core hacks, etc. It's not fun when you have 50 of them.

I've not yet found an ideal (perfectly clean) solution, but my modifications to GitFlow are:

Make a separate branch (other than master) for each customer's production code. Use master for the definitive all-features version, and only merge what the customer wants into their own ones.
Keep developments (or added plugins etc) on tightly defined hotfix and feature branches, and leave them in place, even once merged, so you can merge into other customer branches if you need to. This also makes it easy to keep track of who has what features by crunching through the logs.
When developing new features, branch from the latest common ancestor of all customers if possible. This means that you will be able to merge into develop and then master, but also merge into the customer production branches without (in theory) causing conflicts.
Have one main repo just for development work, which looks like GitFlow. Have another that has your dev repo as a remote, which is used to store customer branches so that your dev repo has a clean(er) history.
If you really can't resolve a conflict easily and need to cherry-pick a whole branch at once, use rebase --onto like this. Just make sure it's clear in the commit messages where the feature cam from and why it's not been merged normally.

Using git has had an added side benefit in that we can now run a cron job across all the production servers which checks for unstaged files in the git repos. We now know if the support staff have been dicking about with the production code on the servers without telling anyone, which has prevented a lot of headaches :)

Hope that helps.

Best Answer

Related Solutions

Version Control – Creating a Version Control Strategy for SVN

Git – an effective git process for managing our central code library

Related Topic