https://learngitbranching.js.org/
It simulates the repo in terms of branches and commits in a graph in the background and introduces every basic command. It also provides exercises in terms of "make A look like B" to prove you understand it.
Yes to teaching Git internals to people but really it should start visually. I've taught Git to dozens of people with no or little technical background and this is how they get it. You start with some variation of "everything is an object" and then go on to "branches are just labels" for these objects.
There was a really great talk where the speaker used wood blocks and pegs to teach Git internals to an audience. I can't find it now, I wish I could.
Games like Oh My Git! and tools like https://learngitbranching.js.org are also very effective.
The video you mentioned, "Git For Ages 4 And Up" https://www.youtube.com/watch?v=3m7BgIvC-uQ, is the best resource for explaining how it works internally, once they have a rudimentary understanding of what git is and why we use it. Watching this video makes future explanations way more digestible. I still sometimes conceptualize difficult git operations in tinker toys.
I highly recommend it even to experienced people.
I have certainly enjoyed learning git from the ground up but the problem I have with it is why? It's like learning calculus without having an application for it. The point of git is to do version control. If you don't get that it's like trying to use calculus to do the dishes.
I'll quote brainbag who replied to my comment:
> On the other hand, the internals of git are elegant and simple, and if you start by teaching from the inside out, it makes it far easier to understand why and when we use certain commands.
It doesn't take much to understand Git internals. I teach it over a short hour to students. And the gift of this mental model will save them hours and days of frustration shadow-boxing a tool they don't really understand later.
I know because I was that student once and I know because I have seen the trouble junior programmers get into when they wield a tool without knowledge.
> What better way is there to explain that than using primitives like cp etc?
These are not real primitives. These are commands that are a part of your parlance. This is what I mean by replacing one set of assumptions with another.
> The point of git is to do version control.
You do this a lot in your article: commit, version control, working directory, are put up early. There's a level of assumed knowledge that straddles somewhere between a novice Linux sysadmin and a complete beginner.
I'm sorry, but people with little or no technical background have no idea what's an "object" in the context of computing. Non-starter unless you have eager students and/or you're a phenomenal instructor (which you might just be if your students come away with an idea of "objects" that are not chairs and tables and things).
Typically I'll say blobs then define blobs as whatever files they're modifying and saving.
If you really prefer to store credentials, you can cache them for a temporary amount of time [3]. The basic command is:
git config --global credential.helper store
[1] GitLab: https://docs.gitlab.com/ee/user/ssh.html
[2]: BitBucket: https://support.atlassian.com/bitbucket-cloud/docs/set-up-pe...
[3] https://techexpertise.medium.com/storing-git-credentials-wit...
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
What exactly is so bad about the ux?
Are the ones having trouble people that's never used another CVS? Is it CLI aversion?
I constantly struggle with git. It's the single tool I use daily that I actively hate.
I think my trouble is the opposite of your speculation here: I think that I'm tripped up because I'm very familiar with a number of other version control systems, and git works nothing like them while at the same time trying to use the same terminology as them. I suspect I need to "unlearn" all other VCSes to understand git, but that's hard to do when I also need to use other VCSes.
But I'm not sure. This is something I've put a lot of time into understanding, because I have a serious "git block" and keep trying to work through it. This explanation is as close as I can get, but feels incomplete.
CLI aversion certainly doesn't enter into it, as I prefer command line tools, and slapping a GUI in front of git doesn't make using it any easier for me.
In any case, I find git to be baffling, opaque, confusing, and extremely nervous-making. The two things that strike terror in my heart are the possibility of messing everything up, and having to do merges.
Saying this is not bashing git. My difficulties here are personal issues. I just have yet to be successful overcoming them.
Not only.
> Is it CLI aversion?
No.
> What exactly is so bad about the ux?
Would any answer satisfy you?
I stopped reading when I arrived at
“…rebasing rewrites the project's history. A desired choice for projects that value clear and easily understandable project history…”
“[squashing] is easy to understand and especially useful if the method of unifying code that is used is rebasing, since the history will be altered, it’s important to be mindful of the effects on the project history.”
I stopped because it’s not clear to me why I should do these things.
This article walks the reader through the very basics, and tackles deeper topics with it’s good to do because it’s important. Pffftt.
Here is a favorite git intro from the wild (2018):