CODEWITHSUNDEEP
gitmergebranchrebase
Horse
Horse

Reputation: 3063

git workflow, and merging changes from master into branches

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

git log pre merge

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

Upvotes: 4

Views: 404

Answers (1)

cdhowie
cdhowie

Reputation: 169468

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.

Upvotes: 2

Related Questions