Maintain branches in GIT without merging with master

Question

At my office, we have a home grown content management system. Slowly but steadily, we have setup 60 instances of our CMS. Yes, we are a big company; an NGO.

Most of our offices use the CMS in its current form. Some of the offices customized the colors, fonts, basically skins. Some others build new features that sometimes we bring into the core. I have been tasked with managing the source more efficiently.

Lets say - I am managing the "Core", and I have office "A" and office "B". Office A customizes their colors only but office B made some changes to the core (not a lot) and their code varies from the Core. I want to be responsible only for the "Core". When I develop a new feature, I want to (upon acceptance), sync these changes with the other offices.

I thought of creating Branches that will never merge with the master. But the changes I do on Master can't go to the branch?? What is the approach I should take and what should I look out for?

Answer 1

This is one possible approach.

For commits in the office branches you want to apply to master, just cherry-pick them on top of master. If you know what you're doing, you could also rebase a series of commits on top of master.

To go the other way, a merge is indeed appropriate; you will want to merge master into office branches, but not the other way around. You would check out the office branch you want to apply the core changes to, and git merge master. This will attempt a merge, but it will only touch the office branch; the master branch will not be moved.

You may also want to consider providing a default list of colors, and allow a new file to be created to override those. You would list the override file name in .gitignore so that those changes are never committed to the Git repository. You would be able to update the default in master and merge that into the office branch, but you'd never see the office color overrides except on the deployed copy.