Using Git to manage multiple forks from master branch for multiple clients

Question

I have a master repository that contains a site I've developed, and I want this master repository to contain the base, generic contents of the product I'm working on. This master repository will be used as a starting point for sites that will be used by multiple clients. Each of these clients will obviously have different settings (such as database connections, and perhaps branding) but will also potentially encompass custom features in the future.

What I was thinking of doing was having the master repository, and then forking per clients from the master branch, and then doing any kind of customizations on those forks. So it would look like:

Master 
   Company A  
   Company B  
   Company C

One of my main concerns is how to synch up changes? I don't think that there would ever be changes in a client's fork that would affect the master, but there are changes to the master that would definitely effect the forks. Is this going to be a huge nightmare? Is this the best way to handle a situation like this?

Answer 1

I would use rebase. This command rewinds your branch to the point it diverged from the master, then replays your changes on top of it. Say you have this (ascii art borrowed from man page):

      A---B---C company_a
     /
D---E---F---G master

Do this:

git checkout company_a
git rebase master

And you'll be left with this.

              A'--B'--C' company_a
             /
D---E---F---G master

All of it is done automatically. On the off chance that there's a conflict, git will pause the rebase and allow you to resolve it. Diff to find the conflicts, then

git add conflicting_file
git rebase --continue

Or chicken out with:

git rebase --abort

This is just a summary, it's all in the man page.

Answer 2

I've lived that and it's an incredible mess. What usually happens is that your workflow will eventually become: forget master and fork from the nearest client. It then quiclky become a nightmare.

I strongly recommend refactoring the code to split things in 2 separated git modules one "core" and one for (each) company-specific code. Without any idea on the exact nature of you repo, it's difficult to say. I've seen both at work and split modules is MUCH more manageable then a bunch of customer branches in the repo.