Exactly. Learning by examples is the worst way to learn git - which sucks for people who learn best by examples, but that's how it is. You often hear people com

Exactly. Learning by examples is the worst way to learn git - which sucks for people who learn best by examples, but that's how it is. You often hear people complaining about git's UX - and I agree that it could be much better, though I'd say its main sin is that it almost actively tries to confuse you into developing wrong mental models on how it works (somewhat ironically, it often does it to provide better UX for those who already understand it). A very obvious example of that would be right there in `git show`, or the equivalent parts of GitHub's and GitLab's UIs. A command that shows you the content of a commit, right? Well, right - it does show you the author, date, commit message... but then it also shows a diff. So, being a beginner who learns by examples, you say - I get it! A commit is a patch! It gets me from one state of the repo to another! Except you couldn't be more wrong. `git show` automatically calculated a difference between the requested commit and its parent to present it to you, but didn't bother to tell you that. Of course, it makes perfect sense - it wouldn't be very useful to show a complete state of the files under the commit in question, it's much more useful to show a diff against its parent(s). However, it doesn't even tell you which commit the diff was calculated against, it's completely hidden by default. How are you supposed to develop a proper mental model of total basics such as "what is a commit" if it hides such essential clues from you? Answer: you need to read up on the theory. There's no way around it, at least not now.