If you don’t know how to work well in a team with Git then you are a liability. If you know a lot of obscure Git commands and how to force changes or rewrite history then you are even more of a liability.
Git is relatively easy once you have the correct mental model of how it works. On small personal projects run “git init” and get into the habit of committing all useful changes. Heck, set up a local directory to use as a file-based remote (a Dropbox directory is good for this if it’s just you working on a project so it syncs over all your machines). That way creating commits and checking them becomes second-nature and mot a chore.
Use a GitHub or BitBucket tutorial and you’ll soon have a good mental model of how it works and the three or four commands you’ll need on a day-by-day basis.
But never ever learn how to force changes through or rewrite history.
If things ever go wrong (you accidentally push something or someone does something foolish) then be very very careful about what you do next.
The safest thing to do, if you can, is to get your local branch into a workable state and then create a commit that makes the changes from the broken state to your state and commit that. I’ve done it, it works, and you don’t lose any history.
With an accidental push you can create a commit that reverses the change with git revert which is a clean and safe way to do things. If you try any cunning history re-writing then you risk someone pulling or pushing whilst you are doing it which leaves an even bigger mess to unravel (see any of the Back To The Future sequels for examples).
I’ve not included any examples because a) I’m not at my computer right now and b) I don’t know any of the commands off the top of my head.
And this is part of the point of this. DO NOT LEARN HOW TO DO CLEVER THINGS WITH GIT.
When you need to fix a source control issue, know what you want to do (create a commit that fixes the problem) but never know how to do it off the top of your head. Google it.
Anything that you know really well you’ll allow yourself to use it more often which means you’ll get sloppy which means you’ll make more mistakes and other developers won’t trust you.
Every time I create a commit I go through every line that has changed and check it. A commit should never be so big that this is a chore (there are exceptions such as package updates if you really must have packages in source control). You should never accidentally commit debug code because you’ve looked through a commit before you push it. It means that your pull requests are never embarrassing either.
Source control is analogous to hygiene. Keep everything clean. When you do anything make sure you leave everything tidy when you’ve finished. Never just sweep things under the carpet.