same project, multiple customers git workflow

Question

Hi,

After my first question, id like to have a confirmation about the best git workflow in my case.

I have a single django project, hosted at github, and differents clones with each his own branch : customerA, customerB, demo... (think websites)

Branches share the same core but have differents data and settings (these are in gitignore)

When i work on CustomerA branch, how should i replicate some bug corrections to the other deployments ?

When i create a new general feature, i create a special branch, then merge it into my master. Then, to deploy on the 'clients', i merge the master branch into the customer branch. Is it the right way ? or should i rebase ?

# from customerA branch
git fetch origin master
git merge origin master

Also, i have created a remote branch for each customer so i can backup the customers branches to github.

It looks a very classic problem but i guess i dont use git the right way

Thanks.

Ju.

Answer 1

I would have a repo called project-master or something like that and a repo for each client. Then, when you have code you need to be available to those client repos, you pull from the project-master to that repo.

Answer 2

I would have a single project repo at a well-known place containing a master branch with the common code, and branches for specific deployments (e.g. customer/A customer/B demo).

Then I would have checkouts from each of these branches for each customer, for the demo server, and so on. You can let these pull automatically from their respective branch with a commit hook on the single project repo.

Every developer would have their local copy of the project repo, do local work, and then push stuff back to the single project repo.

The challenge will be to maintain the branches diverging from master and doing the regular merges so the diversion do not grow over time.

I have seen this solution describe somewhere in much more detail somewhere on the web, but I could not find it quickly again. Some blog post on using git for a staging and production web server, IIRC.

Answer 3

If the three sites share some 'core' code (such as a Django app) you should factor that core out into its own repo and use git submodules to include it in the other projects, rather than duplicating it.

Answer 4

Don't separate the projects in branches, separate them into different repositories.

Make the "common" code generic enough so that costumerA's copy of the common code is exactly the same as costumerB's copy of the common code.

Then, you don't have to pull or merge anything. When you update the common code, both costumerA and costumerB will get the update automagically (because they use the same common code).

By "common" code: I'm referring to the package/series-of-apps that power the websites you're developing.

I'm assuming costumerA and costumerB repositories would only include things like site-specific settings and templates.

The key here is making the "common" code generic: don't let costumerA use a "slightly modified version" of the "common" code.

Also, I'd suggest using a deployment mechanism that doesn't rely on git. git is a great source code management tool; but it's not designed (AFAIK) to be a deployment tool.