Both Git and SVN support the use of branches. However, for SVN, branches are part of a possible workflow and style, while for Git the use of branches is built into the command palette and standard way of working.
One of the major disadvantages of SVN is the way of branching and merging. It can take a long time if you have large repositories. If you create a new branch in SVN, you create a completely new directory within the repository, which means there is repetition in that structure. When the branch is ready or no longer needed, you commit back to the trunk.
A big technical difference between Git and SVN versions before 1.5 is that Git used three-way merges as standard, while SVN used two-way merges. It couldn't perform three-way merges because it didn't store merge information. Git, by using its graph database, can check where the code bases share a common state and then merge from the diversion point, which is then technically a three-way merge. In the latest version of SVN, this is also incorporated because the meta information about branches and merges is kept after merging. Unfortunately, the basic problem still exists – a branch is a full copy (not a reference).
At the same time, there can be changes on the trunk already. Your version of it won't have the changes that are in the branches of developers. This means that you could have conflicting changes, files, or structures that are missing in your branch.
The main reason developers like Git so much is the power of the branching model. Comparing it to the many repetitions in SVN, Git only creates references to a specific commit, so there's less repetition and less waste of space and I/O. Instantiating the reference by creation, deletion, or changing a branch will not affect the commits. Want to try something? Fix a bug quickly? Just create a branch, edit files, and push the commits to the central repository, then delete the branch. Create them lightheartedly!