Taking the SVN model, you are going to have N+1 branches for every N developers modifying the head branch. This gets more complicated once you factor that eventually these branches do not share the same common ancestor (i.e. modification was started from a different commit).
So, even if you only publish a single branch, your tool must support merging and conflicts. Git lets you support branches with a model that handles these simple cases, plus things much more complicated. The benefit for the user is that once you understand this model, it can be applied to the complex actions while keeping the fundamental process the same.
For example, you could create an unlimited number of branches in your local repo that can be merged, modified, re-ordered, adjusted, etc. The commands for handling these operations are the same as if you were working with branches created by others.
Assume though, that your project is just 1 developer who always commits to the master branch (i.e. there is truly a single branch), the architecture of git is far superior to SVN in a number of fundamental ways.
The SHA1 hash of your branch validates the integrity of the entire branch. If any file or commit message is modified, the SHA1 value would change. This guarantees that you will immediately detect corruption of your repo data.
The git repo is self-contain and does not require a server or any configuration. You literally can create a new repo in under 1 second.
Git keeps all your revisions in your local repo. This makes running search and diff commands between changes orders of magnitudes faster than SVN. Imagine finding the commit that changed a line out of 10,000 changes, or finding any change that contained a global variable in code base with 50,000 files or more. Git can return results in seconds when running on ubiquitous SDD drives.
Git tracks content not files. This gives it amazing abilities to easily track files that were renamed or blocks of code that moves between files. Some tools like SVN support renames, but git does this without you having to tell it there was a rename.
Git makes it easier to create a commit that implements a "single logical change". This is important for reading your commit history and when you need to revert specific commits that were later found to either need additional work or become obsolete. SVN will only let you submit a single file at a time, but coding doesn't always happen linearly and sometimes if you forget to submit each change, you'll eventually collect 3 or 4 separate changes in the same file. Git makes it easy to create 4 commits from 4 changes in the same file (however if the changes overlap, you still have to recreate the intermediate states that were lost)