We have project (PHP application), but instalation for each client vary, sometimes very little, sometimes more. Still, big part of source code is common. We manage specific installations as parallel branches to master branch and we need to transfer changes from master to other branches. Same situation was solved in Git: how maintain (mostly) parallel branches with only a few difference? The most voted solution was to transfer changes between braches this way:
git pull git checkout local git rebase master
As mentioned in the solution it creates non-fast-forward pushes after rebasing which I find very unpleasant complication. My QUESTION is - why not to do instead:
git pull git checkout local git merge master
You create (aka "fork") a branch off of master ( git checkout -b AC_feature master ), code/test it, making commits as you go, and then merge it into A and C ( git checkout A; git merge AC_feature and similarly for customer C ).
It is a common practice to create a new branch for each task (i.e., a branch for bug fixing, a branch for new features, etc.). This method allows others to easily identify what changes to expect and also makes backtracking simple.
The idea is you use one common branch, and two (or as many as you need) customer specific branches. All common changes go into the master, and each customer branch gets changes that pertain only to that customer. Periodically (when master is considered to be at a stable point), you'll merge changes from master into the customer branch (
git checkout custA; git merge master
). This brings in newer "common" code into the customer branch. You will never merge the other way -- that would pollute master with customer-specific code.When you make a delivery to customer A, you checkout the "custA" branch and send that. And of course similarly for other customers.
Now let's say you acquire a new customer, "C", and a bit later find a feature that customers A and C want, but B doesn't. You create (aka "fork") a branch off of master (
git checkout -b AC_feature master
), code/test it, making commits as you go, and then merge it into A and C (git checkout A; git merge AC_feature and similarly for customer C
). You do not code it in A and then rely on merging A into C, because that would get all of A into C.If, sometime later, you find a minor bug in that feature, you make the change in the same branch (
git checkout AC_feature; edit/test/commit
), and then you merge it into custA and custC as above.
Source: These refreshingly clear and helpful articles from the developer of Gitolite - Sitaram Chamarty, written in part with direct input from Junio Hamano (Linus Torvalds' partner in maintaining Git).
Maintaining Parallel Customer Branches:
http://gitolite.com/archived/special-branches.html
Followup Article on "Fixing Up" Common and Customer Branches:
http://gitolite.com/archived/special-branch-fixups.html
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With