Currently I use Git on Windows with Visual Studio and I like it. However, I learned Git on Linux initially some time ago. Initially, I was running git-svn for one project I worked at that time. Though git-svn does not allow to take advantage of all Git features, it was good enough for me to find my way with Git and convince myself that Git can be useful for our development. Only after that we decided to convert that repository from SVN to Git.
I think the main advantage of Git is that it is flexible enough to accommodate different workflows. Thus you can choose what fits your development team best. Centralized vs distributed is not a choice between two particular workflows, but more among a large spectrum of possible workflows. If you decide to stay with a centralized workflow similar to SVN, there are still some advantages of using Git.
First of all, you commit your changes before merging with the upstream. SVN forces you to do "svn update" before you have a chance to commit your work. It means that if you made a mistake during this merge, you can lose your work. In SVN, you cannot discard your current merge state and redo it again. Also, you cannot ask a more experience person to help with a non-trivial merge unless this person has direct access to the working tree on your computer.
In general, committing and merging makes your history more truthful as it shows what was the actual state on which your change was made and how you resolved the conflict. The downside is that history is no longer linear. With Git, you can preserve linear history by doing "git pull --rebase" (which can be configured to be default), which makes your history linear as it would be with SVN.
The second problem with SVN is when you commit your changes to the central repository, you never know whether someone else made changes in meanwhile. If those changes were made to different files, SVN will accept your ChangeSet. As result, you have a new state in the SVN repository that no one has tested. Usually, changes made to different files do not cause problems, but sometimes they can. For example, one developer changes some function in a C header and all places where it is used, but the other adds new usage of this function in a new code. Thus you can end up with a broken state on your main development branch even if each developer tested his or her changes. Developers may not notice this breakage immediately until someone says "svn update", but at this moment this person is likely to have his/her own changes, so it can be very confusing in some cases.
Another useful Git feature is that it allows you to try some idea without committing anything to trunk. Then if it does not work out, you can discard it and no one will notice. It is not that I like to hide something from others, but I do not want to force other people to merge their work with my experimental stuff, which may be removed at the end. Moreover removing this experimental code becomes problematic as it is intertwined with other changes. So if you use SVN, your only option is not to commit anything while you are working on this feature. However, it leads to a huge patch-bomb at the end, instead of small logical steps, which is either to review and bisect in case of a problem.
BTW, git-bisect can be really useful to fight tricky regressions in your code. If something got broken, it may not be obvious what and why. So you need to find the commit that introduced this problem and git-bisect is the best tool for this work.
Finally, you have just more options to decide how better to handle some situations. For example, members of your core team can push their changes directly to "trunk" (which is usually called as "master" in Git), but you may not want a newly assigned guy to push his changes without any review. So just tell him to push his changes on a separate branch in the same central repository and then email his mentor, who is going to review and merge this changes if they are good. Branches are really cheap in Git, you should not be afraid of using them. When a short-lived topic branch is merged to the upstream, its name is usually removed, so it won't clutter the branch namespace.
