[hibbelig]

With Subversion, you have a working copy with changes and then you do "svn update", and Subversion merges the upstream changes into your working copy. (But you don't normally call this merge.)

With Git, you have a working _repository_ with changes and then you do "git pull", and Git merges the upstream changes into your repository.

From the user's perspective, it looks about the same. But the Git merges are safer than the Subversion updates, because if the Subversion update messes up your working copy, you're stuck. But with Git, you always have (1) the commits you made locally, (2) the commits you just pulled from upstream, (3) the merge that was done by "git pull". And (1) and (2) can't get messed up, only (3) can get messed up. But you still have both your version (1) and their version (2) to go back to, so you have lots of chances to fix it.

Think of Git branches and the corresponding merges to be like Subversion updates with backups of the previous local working copy.

[kibibu]

> Subversion updates with backups of the previous local working copy.

Which is a practice I got into the habit of doing manually when I used to work with Subversion.