Hacker News Reader

Comment by globular-toast | Hacker News Reader

In my experience, this already starts at a too high level. New devs these days don't even seem to come with a basic idea of what version control is. They think of git more as a workflow used to get code into production. This is why I wrote this article: https://blog.gpkb.org/posts/git-is-a-version-control-system/

View on HN

I'm sorry to tell you this but your article isn't very good at explaining Git. And the commands you're using to demonstrate aren't helpful either. You're just replacing one set of assumptions with another.

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.

I've also taught git to dozens of beginners in a classroom setting, and I have to agree that the OP and GP articles aren't great for beginners, even if they have a technical background. The problem I have with git media is that everybody begins by teaching git's user interface, which is a usability disaster. 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.

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.

Learning git was one of the harder things I've encountered having already used many VCS beforehand. Then one day it all clicked because I'd subconsciously re-engineered in my head how things must be connected under the covers--I wished someone told me to learn about it's internal model. Learning git from commands and workflow is like learning about the world from shadows seen while chained inside a cave.

Interesting because I think completely the opposite and find it ridiculous to start by teaching people about objects and the like. Why do they need to know that? I don't know what you mean by replacing one set of assumptions with another. What assumptions? It's just making copies at certain points when you decide it's the next version. That's the point. What better way is there to explain that than using primitives like cp etc?

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.

> Why do they need to know that?

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.

Fair enough. I've never met anyone who needs to know git but doesn't know how to copy a file. But I've met plenty who know about things like git hash, branch and rebase but have no idea about version control. Like someone who knows how to differentiate but doesn't know what acceleration is.

> "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"..."

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).

That's really a very silly nitpick. I am not directly communicating binary large objects as objects. The point is to communicate blobs in a way intelligible to your audience, to communicate the concept. You have to find your own way to communicate everything is blobs to your audience using language they're familiar with.

Typically I'll say blobs then define blobs as whatever files they're modifying and saving.

I liked this. Thanks!

Reply on news.ycombinator.com