Git Rebase master conflicts

Question

Im having some conflicts on a branch when rebasing master into it.

Scenario is:

Branch off master, make some changes, commit said changes. Checkout master, make some changes, commit said changes, checkout branch-1. Try to rebase master - conflict..

Now I have other developers working in a similar fashion.

Master is kept in sync on all repo's including the webserver, I don't want master's history being changed.

If I solve the rebase conflicts that are conflicting a point in the past, if I checkout master and merge it with the branch - will masters history be changed - or would those conflict resolutions be applied ontop of all the work im merging?

Answer 1

Imagine you have the current situation:

- A - B - C - D
   \          ^
    - X - Y   master
          ^
          branch1

Running git checkout branch1; git rebase master will move the commits from branch1 so that they are applied on top of the master branch:

              master
              v
- A - B - C - D
               \      
                - X - Y 
                      ^
                      branch1

This doesn't change master, but it changes branch1 in two ways:

1. By changing the parent of commit X from A to D you'll change the ID of commit X, in fact as far as Git is concerned it's now a whole new commit (and since X has a new ID, Y has a new parent, so Y gets a new ID too, and so on if there are more commits on the branch).
2. Any conflict resolution you need to do will change the contents of the commits.

If you've already pushed branch1 to a remote repository then it's a very bad idea to rebase it; changing history that's already been shared will only lead to problems.

Assuming you haven't pushed branch1, you can then merge it into master (with git checkout master; git merge branch1), which will result in master being fast-forwarded to commit Y. This gives you a tidy linear history without having to change master:

- A - B - C - D - X - Y
                      ^
                      branch1 AND master

If you have already pushed branch1 then you should avoid rebase and use a merge instead (using git checkout master; git merge branch1), which won't change the history of either of them but will create a new commit (marked M in this diagram) on the master branch:

- A - B - C - D - M
   \            / ^
    - X - Y - -   master
          ^
          branch1

Answer 2

If you rebase, regardless of which branch you rebase into, you are changing the history of your repository. The idea is that when the other developers people pull master (from say origin) after you have pushed, their repos will be up to date as well.

To be clear: merge conflicts while rebasing will not change the history of master. Rebasing as a merge method will.

If you want to not change the history of master, you cannot rebase as a merge method. The default git merging behavior should work just fine for you, conflicts or not.

git checkout master
git merge branch-1