You only need to understand {init,commit,diff,status,push} to use git. When something goes wrong you can delete your .git and start new. This obviously not what you want when you have a codebase with collaborateurs somewhere public accessible, but its fine to get used to it.
Telling someone to "delete your .git" is actually TERRIBLE advice. This should never be necessary unless you go screwing around in .git and break internals. It has a high probability of causing irreversible data loss. It's exactly the worst habit to build if you want to start collaborating.
If your repo ends up in a weird state, learn how to fix it. It should not be terribly complicated, especially if there is no rebasing happening.
That's only true if you don't want to undo any changes. What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those?
Keeping a "bar copy(2) final working.py" file is not about having a nice looking timeline, it makes it very easy to get back to a working state. All you need is copy and paste, or keep the working function as a comment in bar.py. You can see your working code and know you're not messing with it when you're experimenting with bar.py. I'm not saying that's the best way of doing it, but it's a very common use case that's not usually addressed in git guides, where it's all about pushing commit after commit, maybe branching, maybe pushing to a remote with others, but rarely enough focus on undoing mistakes after some experimenting if you didn't branch first.
> What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those?
You are operating under the assumption that foo() changes in a vacuum. That is an invalid assumption for lots of software changes.
Commits are supposed to contain one logical change each. That logical change may or may not cross function boundaries (often it will).
Reverting a commit should revert the logical change. That is how you accomplish what you're after in git.
I've seen so many people do the "select function body, copy, toggle comment, paste copy of function, try out ideas on this new version" workflow. I've done it plenty too in Matlab and similar during various labs at school. I'm not talking about best practice during software engineering, I'm talking about having the confidence your code can easily get back to a known good state if you want to experiment, like beginners should do a lot of.
And plenty of times functions are self contained enough that you can change the function body without changing other code as well.
