Beej's Guide to Git

I regularly conduct 2 hr long "Intro to the Git Data Model" courses at my workplace (1-2 times a year). I literally take them into the .git directory and unzip the files to show how everything is just plain text representation of basic data structures. It's honestly cool to see it click in their heads.

We have a basic Git cookbook we share with any new joinees so that they start committing code, but most of them just follow it religiously and don't understand what's going on (unsurprisingly).

However, literally everyone who attends the course comes out with a reasonable working understanding of Git so that they know what's actually happening.

That does NOT mean that they know all the commands well, but those can be trivially Googled. As long as your mental model is right, the commands are not a big deal. And yet, the vast majority of the discussion on HN on every single Git post is about the command line.

Funnily enough the class sounds a lot like the alt text of https://xkcd.com/1597/ (Just think of branches as...), the difference is that that is unironically the right way to teach Git to a technical audience, and they will come out with a fundamental understanding of it that they will never forget.

I honestly think it's such a high ROI time investment that it's silly to not do it.

I did it once, I was indeed really nice, and the discussion that we did after was very cool. I put in the last slide of the presentation some questions for my colleagues answer based on the Git data model, e.g.: "Can we move a commit to another branch?" or "What guarantees that we don't have cycles in the commit graph". I was really satisfying that people came out thinking Git, not only using it!

Exactly, and it's such a high success rate!

This is precisely why it enrages me when all HN discussion about Git devolves to the same stuff about how it's complex and this and that.

A technical person who has general sense about basic data structures (Leetcode nonsense not needed) can be taught Git in under 2 hours and they will retain this knowledge forever.

If you can't invest that little time to learning a tool you will use everyday and instead will spend hours Googling and blindly copy-pasting Git commands, that's on you, not on Git.

That last question is a cryptography question in disguise; the answer is "the fact that SHA-1 collisions are still impractical for most people".

Is there a copy/video of your talk, or a similar one you recommend?

> I regularly conduct 2 hr long "Intro to the Git Data Model" courses at my workplace (1-2 times a year)

Does the course material (and perhaps any recordings) have any proprietary information or constraints to prevent you from sharing it publicly? Is this based on something that’s publicly available yet concise enough to fit within two hours? If yes, please share (perhaps in this thread and as a post submission on HN).

I’m asking because I believe that there can never be enough variety of training materials that handle a topic with different assumptions, analogies, focus, etc.

Share your video!

> As long as your mental model is right, the commands are not a big deal.

A priori, I would have assumed this was one of those "just understand how every layer and every part of Linux works, and using Linux is easy" type arguments people used to make in the 90s - i.e. theoretically true, practically infeasible for most people.

Thankfully, I was lucky enough to come across a video explaining (some of) the git internal model early on, and it really doesn't take that much or that deep a knowledge of the internals for it to make a big difference. I'd say I know maybe 5% of how git works, and that already gave me a much better understanding of what the commands do and how to use them.

Correct!

Even though SHA-1 collision were achieved, they are impractical and we can make the assumption that "if two objects has the same hash, they are the same".

To have a cycle, both commits involved would need to have the hash of the other, which is impossible: the hash of a commit is based on its content, its content contains the hash of its parent.

We could only have a cycle here if we create two commits created after two arbitrary hashes.

Perfect!

Git is only a directed graph with the adjacencies stored as hashes. Everything else is just tooling around that data structure. No problem using Google to find the commands (the Git CLI is very inconsistent...) but if you know what you want to do with that data structure you can find precisely the commands for that.

Not the OP, but I've been teaching along similar lines. I've done it a couple of times at conferences—here's one of the versions: https://www.youtube.com/watch?v=8Q-frNO-yps

I've also blogged about it

- https://looselytyped.com/blog/2014/08/31/gits-guts-part-i/

- https://looselytyped.com/blog/2014/10/31/gits-guts-part-ii/

Posted this comment https://news.ycombinator.com/item?id=42961468

Happy to get any feedback.