Git workflow and merging changes with the master on branches

Question

With difficulty with SVN, I was told that I had to check out the GIT, as the branches would be perfect for the workflow that I was trying to achieve. I was already confused and thought that I have the basics of git sorted now.

We basically have a central structure that some of our clients use, and I want to have a trunk / master and use branches as usual for dev / try stuff, but I would also like to create branches for each client, so I could work with specific changes to the client in the code. These branches were always a branch and never ended up merging back into the trunk / master.

The main thing I'm trying to achieve is that I can easily merge all FROM trunk / master changes into different client branches, and I am embarrassed if I need to merge or reinstall.

So my question is ... Should I always use rebase for this, and if so, why? (because I want to keep separate commits in each branch?)

Change So I create a repo, and in this repo I will say file.php with $x = 1

• I do it to master
• I create a client1 branch
• In client1, I add a new file and commit
• In client1, I am changing the .php file, so $x = 2

• In master, I make changes 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'm adding a new line to file.php adjacent to $x that causes a conflict?

Answer 1

You have to merge. Rebasing will accept all changes to master, as the branch deviates from the master and re-creates them on top of the branch. This means that each commit on the main will be duplicated for each client branch that you are tracking.

Merging is semantically what you do. The resulting commit graph will look much nicer, and Git will have an easier merge execution time, since after each merge the wizard’s history will become part of the branch’s own history - Git will only need to consider the commit on master since the last merge, instead of reviewing each commit on master.