-1

I know what $ git rebase does in the background. Assume this:

A -- B -- C
      \
       D -- E

$ git rebase will remember all changes we made in e (base is b) and apply them in base c. So the result is:

A -- B -- C -- D' -- E'

Now I want to know, what $ git merge does in the background? Actually the interesting part is "why merge has a possibility of conflict but rebase doesn't"?

Martin AJ
  • 6,261
  • 8
  • 53
  • 111
  • 4
    Rebase do have conflicts!!!! – Francesco Aug 19 '17 at 14:22
  • @Francesco Really?! I read somewhere: one way to avoid conflict is using `rebase` before `merge` *(not sure about the quote, but something similar)* – Martin AJ Aug 19 '17 at 14:24
  • 2
    Possible duplicate of [What's the difference between 'git merge' and 'git rebase'?](https://stackoverflow.com/questions/16666089/whats-the-difference-between-git-merge-and-git-rebase) – Joe Aug 19 '17 at 14:32
  • Rebasing can *absolutely* cause conflicts, but using rebase instead of merge will typically result in a cleaner history and will often make it easier to contribute your changes to an upstream source (or merge them into something like a release branch locally). There's lots of good documentation out there on the difference between `merge` and `rebase`. – larsks Aug 19 '17 at 14:33
  • @larsks ok thx. Just can you please tell me when **should not** I use `rebase`? – Martin AJ Aug 19 '17 at 14:40
  • If you do a rebase before a merge you avoid conflicts in the merge only because you tackle them in the rebase! – Francesco Aug 19 '17 at 14:50
  • A point to remember is that when you rebase, your commit ID's change. That means that you **must not** rebase commits that are already pushed to a remote. – cst1992 Aug 23 '17 at 17:49

2 Answers2

1

to avoid conflict is using rebase before merge

Yes indeed: to avoid conflict when you will have to merge your branch to its upstream branch (when pushing, for instance): from your schema, the merge will be a fast-forward one.

Plus, you can train rebase to remember the conflict resolution you might have to do, meaning you can rebase multiple time without having to re-resolve all the same conflict. See git rerere (works even if you did not initially activate rerere, or you can do a manual retraining).

That is why I recommend rebasing (pull --rebase) before pushing (also in this answer): you resolve possible merge conflicts locally (in your local repo), before pushing back your local commits.

But make no mistake, a rebase will re-apply each of your commits on top of the other branch using a merge strategy. So merge conflicts can occur then.
This will be better expressed in Git 2.14.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

Conflicts have nothing to do with commits and everything to do with tree comparison.

If you make some changes in files A, B and C in branch 1, stash your changes and move to branch 2 where the contents of B are different, you'll get conflicts in file B. This is despite of you not making any commits whatsoever.

Merging and rebasing work in different ways. One of the most fundamental differences between merge and rebase is that a merge commit has multiple parent commits - if you'd ever wanted to go back from a merge commit, you'll have to specify the parent number.

The way the merge commit is made is that if the branch to be merged has 4 commits for example, then the merge commit is made on top of the main branch with changes equal to the sum of the changes in the 4 commits(similar to what you get when you squash commits). If you get conflicts, you get all the conflicts of all the changes at once.

Rebasing is different - changes are applied commit-by-commit. If there are conflicts in commit 2, then they have to be resolved before 3 is applied. The ID's of the commits are also changed to indicate that these are rebased commits.

cst1992
  • 3,823
  • 1
  • 29
  • 40