A video in which I try to explain what merging and rebasing really are, to help you understand what is going on when Git presents you with scary-looking conflict messages. I also explain why you shouldn’t panic because it’s hard to lose your work, and how to get you work back if you really mess up:
Slides here: Difficult Merges in Git.
A commit represents the state of the world (and the history leading up to that state). A commit is not a diff.
Merging means making a new commit with two (or more) “parents” (previous commits) that represents the result of merging the changes from two different threads of development that happened separately. None of the already-committed commits are modified – you just get a new commit on top. History is more complicated, but true.
Rebasing means modifying the history of one thread of development so it looks like it happened after the other one. This involves modifying all the commits in that thread. There is no extra merge commit, so you lose the history of the merge that happened. History is simple, but it’s a lie, and if you messed up the rebasing process, you can’t get back to where you were (once your old commits have been garbage-collected).