Git Version Control – Can Git Versions Vary Between Team Members?

If I read this properly branches are basically a one-shot deviation from your main line of development, never meant to be merged back into the main line and advances in the main line never get applied to these branches. The only deviation would be that bug fixes appropriate to the version the branch was based on need to be applied to the branch.

The answer now pivots on your day to day workflow, the number of developers working on any one branch or number of changes are red herrings. I see your primary need as wanting to know what branches get a bug fix update from a main branch change and for this I think that the combined repository with branches will be more efficient since it's all in one place. Were there never any need for cross pollination then separate repositories would enforce that, but that scenario doesn't match the reality of your project as I understand it.

The Driessen model would work well if your project needed to merge branches back into the main line of development, but you do not need that. Even so I think that there is merit in maintaining an InDevelopment and StableRelease concept if you're working on a product that's live.

So to summarize I think that your project would work well with your branching model plus a dash of Driessen for your main line. Your mileage may vary; I've always worked with a "pending release " branch that turns into a "live" branch and a separate "next release" that all require cross pollination of fixes and changes at various points so my perception may be biased.

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.