This book is over 500 pages, but chapters 1 to 3 will get you up and efficient within 2 hours. Especially chapter 3 (I skipped to it, I kinda knew the basic git commands from "experience"), which goes over branching and how it works. It explains how snapshots are handled and what points to what, which make working with multiple branches locally and remotely a pleasure actually.
It's honestly not to hard to get decent at git. Although I never realized how much of a tool git was until I heard about people writing 500 page long books about it.
This whole thread is evidence of two opposing viewpoints: "git is too hard" and "git is powerful, professional tool and that requires some effort".
I believe those making the latter point misunderstand the first group (to which I belong): I'm not opposed to putting in some time to learn a tool that's central to my craft.
But git seems to often be complicated not because of the complexity of the underlying problems, but because of choices made in its implementation.
Consider: If you have a decent understand of information theory, you'll be able to use any database system within a short time, even if you never had heard of SQL before. Indeed, with a few years of SQL, you'll quickly understand NoSQL systems as well – coming from Postgres, I was productive in Redis within half an hour.
But no amount of experience with VCSs will allow you dive into git without hitting a brick wall.
Most people use it like a svn with better branching and merging.