One way to look at it: in some ways Git provides a framework for almost any workflow you could possibly want. It optimizes for workflows that major users of Git care about, such as the model followed by the Linux kernel and adopted by many other projects. But Git won't enforce very much structure on you; you impose that on yourself. As a result, you can use it almost exactly like SVN, at which point it'll feel like a gratuitously different SVN. However, as you find and make use of the other possibilities available to you, you'll have more success using Git.
Some of the first things you'll want to look at: doing many small commits, using many lightweight branches, and using commit --amend or rebase -i on local changes to fiddle with them before pushing them. Think of each branch as the result of your work, despite it containing many commits; you can edit the branch as a whole until you get it right, and then push it, much like you'd edit the SVN working copy until ready to run "svn commit". You get to have more structure in your working copy, and keep that structure when you push to the public repository.
One big recommendation, though: learning Git works a lot like learning the UNIX command line. You can learn a pile of individual tools, but it also helps to know the philosophy of how they fit together, so you can more easily string together impressive ad-hoc solutions when you need to. I'd suggest reading more about Git's repository structure, and thinking about it more as a DAG, and how the commands fit in that model.
Some of the first things you'll want to look at: doing many small commits, using many lightweight branches, and using commit --amend or rebase -i on local changes to fiddle with them before pushing them. Think of each branch as the result of your work, despite it containing many commits; you can edit the branch as a whole until you get it right, and then push it, much like you'd edit the SVN working copy until ready to run "svn commit". You get to have more structure in your working copy, and keep that structure when you push to the public repository.
One big recommendation, though: learning Git works a lot like learning the UNIX command line. You can learn a pile of individual tools, but it also helps to know the philosophy of how they fit together, so you can more easily string together impressive ad-hoc solutions when you need to. I'd suggest reading more about Git's repository structure, and thinking about it more as a DAG, and how the commands fit in that model.