Handling one code base for multiple clients, with their own custom code

Branches are the wrong solution here. Branches are for when the code (temporarily) needs to change from the common base.

The problem with branches is that changes made to one branch stay on that one branch until you explicitly merge them onto another branch. This effectively means that if you have a change in the common code, you need to apply that change to each 'client-branch' individually, which is exactly what you don't want.

I am not fully up to date with git terminology, but the better solution is to have several repositories/sub-modules. You then create one repository for each client and an extra repository for the common code. The client's repository can then include the common repository as an external reference or sub-module and any change made to the common code is then immediately available to all clients repositories without additional work.

Branches might be ok. When the code changes, i.e. new features are written, bugs are fixed, etc, then they are added to master and then for the new areas to receive it they should fetch/pull the latest master and/or rebase their branch against it to get the new changes. They can then push the updated branch to github to make sure that the latest version of it is also stored there.

Another option is for other areas to fork the project. This is basically a similar process in terms of getting updates (fetch the latest master and rebase on it).
The difference with forks is that they don't automatically get accepted into then main remote, they have to be approved by the github repository owner (or others who have been given that privilege).

There are lot of issues when you have different code files for each client with each own module, theme etc. All this code is actually a different code base, probably with similar or identical logic to another client code base. Apart from the initial development time, which is something that I personally fall in with a lot of times in the past, maintaining and refactoring such code will definitely be a daunting task. To my mind, you should have a single codebase with all client customizations, if you don't want to changes to every single client code.

For drupal and wordpress we have a similar problem -- there is a core which gets updated from one direction and then some site-specific files which come from another direction. The solution we came up with was a combination of effectively forked repositories and sub-repositories.

First, for the repositories what we do is create a template project / site incorporating our project layout and configuration scripts and bits with the default application setup in our project. This is setup in a branch -- say wp-default for wordpress -- rather than in master. To spin up a new project, we init a new repo and pull from the default project. We then merge the wp-base branch into the repo making master have a clean copy of our site's setup. We don't actually fork things as the updates aren't going to ever flow back, rather the concrete project will pull updates in from time to time.

For your theme and other customizations, they would just land in the project normally from here on out. When there is an update to the core, you pull changes in from that default project and then merge them into your working copy.

The subrepos kick in for content -- we put the sites content and databases into a subrepo, mainly because we've seen content kill repositories so we want separability and also it makes it easy to automatically update an independent repo. A script copies them into appropriate places or forcibly restores things.

This will work brilliantly so long as your theme and customizations are happening in separate files and things are not horribly intermingled. Having a fully independent end-repo makes it possible to jam in any hacks you need on the pointy end -- we have had to hack the drupal / wordpress core a few times for good and bad reasons.

Here is what I have come up with for my solution.

For a start, I'm the only person who can use git properly (ish) so any command line stuff is out of the question, people just want to use github for windows as "it's pretty".

So I have the core code, with themes and everything in one repository, stable in master. When it comes to creating a new project I just copy and paste it (since you can't fork to your own account) into a new repository.

To update it, I can download the master and literally extract it over the top, so all the core files get replaced.

The master has the database file as "_database.php" so doesn't overwrite anything.

To speed up development on the front end, all CSS and JS is on a local CDN and the core calls it with a random number on the end to always fetch a non-cached copy.

I have written a script which get the latest master, extracts it and dumps it over the top of all code running the CMS which is running perfectly!

So thats it, it keeps all the code up to date, and if a client wants a completely different site it can change and not be updated again. All code is in separate repository so they can have their own master and development branches.