views:

258

answers:

2

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
+1  A: 

Greg's answer to your other question seems to view different branches as remaining local to particular installations, not pushed to other repos (emphasis added):

If it's local to a system, commit it to that system's "local" branch, else commit it to "master" and push it up to a common repository.

You almost always want fast-forward pushes to branches in a shared repository. The git rebase documentation explains how to recover from an upstream rebase (i.e., git rebase then git push -f), and it's no fun for anyone involved.

For another approach, see Never merging back:

There are valid cases where you once fork with the intention to never merge back, but in general you should try very hard to keep changes on such a fork to the minimum.

The author goes on to discuss branching policy for various customer releases within the same repository.

Greg Bacon
+1  A: 

It really depends on what you want to do with the branch. Yes, if you rebase local, it'll create non-fast-forward pushes after rebasing. On the other hand, you'll be maintaining a set of distinct changes going forward and what's on your branch will be a set of changes AS IF THEY HAD BEEN MADE TO THE NEWEST HEAD OF MASTER.

Merging the master to local, instead, will keep local marching forward in time with master, and will record the history as it happened. If you need to be able to reconstruct the state of local in the past, then you'll want to do this. The history will never change. But, you'll have a more complicated history to deal with.

John Stoneham
On my team, we (almost always) rebase any branch that's going to merge back in. As often as possible, to make the rebase easier. That simplifies the understanding of the change history when you come back.When we have to maintain two branches in parallel and we're releasing off both (maintenance and development versions, like) - then we can't rebase anymore, it's too confusing. We start merging instead.
John Stoneham