> Git is so pervasive in software development that I think you will be at a disadvantage if you give up on it.

I would call BS on this. Yes, git is pervarsive, but if you learn alternative tool (mercurial, perforce, even svn), you will find that learning git (at least for being productive on team that uses git) is straightforward.

Also, haven't seen a company that actually tried during interviews ti figure out if you know how to use git or not.

Disagree. I learned Git after working with SVN for years. Knowing SVN put me at no advantage whatsoever. If anything, I had to actively get SVN habits out of my brain to make the most out of Git (e.g. SVN trains you to avoid branches because their merging is a hot mess, but in Git, branches are everywhere).

But you were able to be productive on those projects with git, even if you didn't use it optimally, or to full extend, right?

Sure, but that's moving the goalposts so much that you're invalidating your entire premise.

I agree with this first paragraph. But disagree with the second. Depends on what kind of learning style you have but I don't think a book is the best format for learning git (or most programming concepts for that matter). You probably already understand most concepts of git already anyway, but the devil is in the details and it sounds like that's where you're getting stuck. If you're a book person for technical things, though, then go for it.

I'd suggest that anytime you go into a situation where you're not sure if you'll mess something up, just make a full copy of your project on your local file system. Then try stuff out on the copy. Then you can try branching and such without the fear of messing anything up. Once you get it, you can repeat the process over and over to make sure you know it. You have to be able to fail without fear of wasting days of your time.

I have to agree with this. It's an essential skill. There are great courses on LinkedIn and Coursera for free (even if you don't get the respective subscriptions).