Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Every tutorial I read falls in two camps:

1. try to be helpful and simplify commands to the extreme, possibly resulting in an subverted (in both the actual and software sense) and damaging explanation (e.g git add)

2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand.

Both equally fail at making people get git.

Having explained git an inordinate number of times to various people, I started writing here all I ever needed to introduce people to git in a few minutes†, but it takes longer to write than to explain hands-on and face to face. I'll complete this and make a gist out of it.

† For varying definitions of "few" and possibly "minutes", but honestly much less than people make it sound about git being a horrendous, unlearnable, complex system with a broken UI. It's simple, it's brilliant, you just have to set the bar right in between 1. and 2. when teaching it.



Your "second camp" of tutorial works exceedingly well at getting other hackers to understand how git works. Git "clicked" when I learned the internals, teaching me about various porcelain commands and their flags without teaching me what git actually is did nothing for me.

The reason why so many people are keen on teaching git by teaching how it works is because that is how they learned git.


This is true, if you actually care. Many people don't want to have to know the inner guts of how every tool they use works and just want to get their work done. It's unfortunate that git seems to (almost) require it (most likely because of its inconsistent UI (which has gotten better)).


The way I see it, the CLI stuff is a distraction, when you "want to learn git", what you really want to do is understand how a DAG can be used for version control. Git is the idea. The standard/stock CLI is just one of many imperfect realizations of the idea that is git. Getting the handle of that particular realization of git is an unfortunate distraction that is needlessly weird in some cases.

Think of it like the difference between learning how an engine works, and learning how [some particular engine, in some particular car] works. The first is pretty simple and illuminating. The second has lots of annoying details and imperfections. If you want to work with cars, you learn the former first.


Agreed. I sorta knew the details before, but this article laid out the meaning of refs, trees, branches, and tags in a way that finally clicked for me. Would it have helped me get started with git back in the day when I only grokked Subversion? I can't say for sure now, but reading it today it clicked in a major way.


Your second paragraph hits the nail on the head. It's the Feynman Technique for learning.

See: http://www.scotthyoung.com/learnonsteroids/grab/TranscriptFe...


2. describe in succinct, painful accuracy git internals (the OCD hacker way) when no git newcomer actually cares about tree objects first hand.

While true, there's also a category of git users who are no longer really "newcomers" but still use git primarily as a subversion emulator and want to learn more.


+1

I'd love to see your notes.

I found that when I was learning git there were two concepts that were crucial: understanding the staging area, and understanding the very basics of the DAG (not talking about tree objects, only spending just enough time to learn how to merge and rebase).

I have to say I was a little disappointed this tutorial didn't even mention the word staging, since it's pretty important to being able to use the interface.


Definitely interested in seeing your notes, even though there are a staggering number of git tutorials around.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: