Question

I understand that re-base is good for situations when you want to add a fix to a base branch and put it in all other branches. but it seems much more complicated than a merge(much more conflicts).
Am I missing something?

Answer 1

In general, it is a good practice to use git rebase when you are working on non-published things – local things that you have not pushed (or you have pushed to a place that other people are not pulling from). Rebase rewrites history, so people pulling will have issues if you rebase, while merge does not rewrite history, thus does not cause issues for other people.

While merge will try to merge your changes using a merge strategy, rebase will just fetch the HEAD of what you are rebasing against and then try to apply your changes. Since it loses the time of when your change was made, it can not solve conflicts as effectively as a merge.

Usually rebase is not much more complicated, unless you are in a relatively small codebase where a lot of developers are working at the same time and stepping on each others toes OR you leave your code for a long time.

I think this is a good resource to read about rebase: http://www.jarrodspillers.com/git/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell.html

Jarrod defines the “rebase rule” very well: Don’t rebase branches you have shared with another developer.