The Guide to Git I Never Had | Hacker News Reader

The Guide to Git I Never Had

glasskube.dev

43 pointsthunderbong21 comments

I loved this back when I was first professionally using Git.

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.

I use this to explain git to any junior having troubles.

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/

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!

One really important tip that's quite often forgotten when teaching git is: if you're worried what will happen, commit all your outstanding work, create a temporary branch and try it out.

Nice overview! Personally, I'd like to argue against storing credentials in plaintext on disk. The usual suspects all have ways to use SSH keys [0-2].

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

[0] GitHub: https://docs.github.com/en/authentication/connecting-to-gith...

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

The git book has a good section on the intervals of git which helps you understand the program overall:

https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...

This blog is a great beginner's quick-start guide. If you want to learn more about Git usage in detail, I recommend reading https://git-scm.com/book/en/v2

I don't get the "git has horrible user interface" crowd. Never had a problem understanding git or its commands. It's probably the least complicated tool in my box, and the one that has given me least trouble.

What exactly is so bad about the ux?

Are the ones having trouble people that's never used another CVS? Is it CLI aversion?

> Are the ones having trouble people that's never used another CVS?

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.

What's the other version control you use?

> Are the ones having trouble people that's never used another CVS?

Not only.

> Is it CLI aversion?

No.

> What exactly is so bad about the ux?

Would any answer satisfy you?

I skimmed it for better description of core ideas than my understanding. I kept feeling this was some kind of AI article. The sentence phrasing is off to me.

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

https://www.robinwieruch.de/git-essential-commands/

Reply on news.ycombinator.com