"Conflicts" mean "parallel evolutions of a same content". So if it goes "all to hell" during a merge, it means you have massive evolutions on the same set of files.
The reason why a rebase is then better than a merge is that:
- you rewrite your local commit history with the one of the master (and then reapply your work, resolving any conflict then)
- the final merge will certainly be a "fast forward" one, because it will have all the commit history of the master, plus only your changes to reapply.
I confirm that the correct workflow in that case (evolutions on common set of files) is rebase first, then merge.
However, that means that, if you push your local branch (for backup reason), that branch should not be pulled (or at least used) by anyone else (since the commit history will be rewritten by the successive rebase).
On that topic (rebase then merge workflow), barraponto mentions in the comments two interesting posts, both from randyfay.com:
- A Rebase Workflow for GitA Rebase Workflow for Git: reminds us to fetch first, rebase:
Using this technique, your work always goes on top of the public branch like a patch that is up-to-date with current
HEAD.
(a similar technique exists for bazaar)
- Avoiding Git Disasters: A Gory Story: about the dangers of
git push --force(instead of agit pull --rebasefor instance)
