git工作流程，并将更改从master合并到分支

Question

Having struggled with SVN I was told I should check out GIT, as the branches would be ideal for the workflow I am trying to achieve. I have been muddling along and think I have the basics of GIT sorted now.

We basically have a central framework that some of our clients use, and I want to have a trunk / master and using branches as normal, for dev / trying stuff out, but I would also like to create branches for each client, so I could work on client specific changes to the code. These branches would always be a branch and never end up getting merged back into the trunk / master.

The main thing I am trying to achieve is so that I can easily merge all changes FROM the trunk / master TO the various client branches, and I am getting confused with if I need to merge, or rebase.

So my question... Should I always be using rebase for this, and if so why? (because I want to keep the individual commits in each branch?)

Edit So I create a repo, and in that repo I have say file.php with $x = 1

• I commit that to master
• I create a branch called client1
• In client1 I add a new file and commit
• In client1 I change file.php so $x = 2

• In master I make a change to file.php but its a new line, and $x remains $x = 1
• In client1 I merge master and get a conflict on $x

Is it because I am adding a new line to file.php adjacent to $x that it is causing the conflict?

Answer 1

You should merge. Rebasing will take all of the changes on master since the branch diverged from master and recreate them on top of the branch. This means that each commit on master will be duplicated for every client branch you are tracking.

Merging is semantically what you're doing. The resulting commit graph will look much nicer, and Git will have an easier time performing merges since, after each merge, the history of master will become part of the branch's own history -- Git will only have to consider the commits on master since the last merge, instead of reconsidering every commit on master .