> you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
https://www.cduan.com/technical/git/
this tutorial was an absolute revelation for me. I can't recommend it strongly enough.
Ps: I also found git destroying my work via git reset to be really annoying so I built a safety net. https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29
Even knowing graph theory and understanding git I still don't have the shortest idea what https://eagain.net/articles/git-for-computer-scientists/git-... this even wants this to be.
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. 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 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.
There's another that was useful, I'll dig it out and update this comment.
This one helped me a lot: https://alexwlchan.net/a-plumbers-guide-to-git/
Raymond Chen is excellent.