I've used both Git and SVN and where appropriate I usually strongly favor Git (or alternatively Mercurial, the other popular distributed version control) except in certain situations.
That said, I will say as a very heavy Git user that while a GUI helps, it's NOT going to make a distributed version control system like Git or Mercurial immediately intuitive to someone used to using centralized version control (like SVN) right away because it's more than just the UI and software that makes them different.
Distributed version control is designed around a very different way of working, and the whether Git is beneficial to you depends on whether you benefit from the workflow it allows for.
As an example, I use Git for almost all my programming projects (with some notable exceptions I'll get into later) even down to my own personal solo projects, but the way I work with Git is VERY different from how I work with SVN.
I use branching and merging a lot more in Git than I would in SVN, and even for a solo project (and most of my projects are solo) I sometimes have ten or more branches going at a time and I transition between them very frequently as I work. That probably sounds excessive to some people, but once you get over Git's initial learning curve making and managing branches becomes much easier than SVN and there's little reason not to do it. This allows me to work on several, possibly conflicting, feature sets simultaneously with no friction between them, because I can keep them isolated until I'm ready to integrate them.
I also sometimes have multiple remote repositories for a project that may be in different states, or may even have different branches on them. I may have a private BitBucket remote repo for some new features I don't want public yet and a public GitHub repo for all the features I want out there, and perhaps I might have a self-hosted remote as an emergency and/or offline backup. Even if all those are inaccessible somehow, I have a complete repo on my local machine so I can keep working. Managing such a setup in SVN would be a pain in the rear, but in Git it's pretty easy because Git was built from the ground up to accommodate that sort of setup.
Of course not everyone uses Git this way, but you get the idea. I prefer Git because my preferred workflow is actually easier in Git than in SVN, and that's not necessarily going to be true for every developer or project.
There are some things I do not use Git for, and that's projects that involve lots of binaries and large non-text assets. Git can do a lot of the things it does because it replicates the repo storage and history on all the machines the repo exists on, which is awesome for projects that are mostly code but is very problematic when it comes to projects with large assets as they bloat the repos very quickly.
Things like games or game-like software often run into this issue.
For these kinds of projects I prefer to back up those assets separately, or in some cases use SVN to manage them.
I guess the point I want to emphasis is that Git is not a direct alternative to SVN, they belong to different approaches to version control and if you try to use one the same way you'd use the other then you're going to be in for a bad time.
If you want to try switching to Git or Mercurial and you are used to using SVN, Perforce, or TFS then you should be aware that distributed version control is going to involve a steeper learning curve and added complexity, and you should consider whether or not the benefits are worth it to you.
