Branching is not evil, merging is not evil, SCM tools that can’t do merging well are (creating branches is usually ok, making them interact with each others usually isn’t, CVS can’t do it, SVN can’t do it, … let’s not talk about SourceSafe please).
That’s why trying a distributed VCS such as Mercurial or Git is, in my opinion, a breath of fresh air: since they’re based on the concept of merging (each checkout is basically an anonymous branch, each local clone of a repo is an other anonymous branch, and you can easily create branches of branches of branches), they have to have good merging models, or they just don’t work.
And they do work.
What makes git so different (better?) than subversion on this aspect ?
First of all, it tracks merges, which means that Git knows which revisions you have and which you don’t (when it talks to another Git repository). Subversion doesn’t, so you have to manually track revisions in order not to repeatedly merge them in, and it’s error prone, and it usually doesn’t work.
Second, when it merges two branches/trees, it doesn’t take all the changes of one branch and put them in the other one in a single, ugly, horrible, unusable revision, it leaves the two branches in parallel and creates a “merge revision” in which you basically handle the disparities and incompatibilities, if any (most of the time, there isn’t any and the merge revision is only there to say “this is the union of branches A and B at point C”). Plus that tracking allows you to create wonderful committrees such as http://repo.or.cz/git-browser/by-commit.html?r=git/repo.git
Third, it has very aggressive merge matching, which means that it resolves merges fast, it finds conflicts only when there are conflicts (usually) and it mostly doesn’t find conflicts, especially when there aren’t any, so merging between your branch and someone else’s branch boils down to pulling his branch into yours and calling something along the lines of