
Understanding Git - cduan
http://www.eecs.harvard.edu/~cduan/technical/git/
======
mark_h
That is actually one of the better intros I have seen, which surprised me
some-what (there are quite a lot of introductions to git now!). Possibly I've
just used git enough by now -- albeit not intensively -- that it was easy to
follow, but I completely agree with his contention that you have to understand
the repository format to understand git, and he does a good job of of covering
that in context.

Scott Chacon's gitcasts included a keynote he gave which also has a good
explanation of the repository and how it works:
<http://www.gitcasts.com/posts/railsconf-git-talk>. He has a peepcode book
covering the same material, which I bought out of appreciation for gitcasts at
the time.

~~~
mechanical_fish
I was going to say that at first glance this writeup resembles Scott Chacon's
general approach in his Peepcode book, which is good.

------
silentbicycle
Good tutorial. I think this is a more meaningful approach than e.g. trying to
explain git in terms of SVN, because that reminds the reader of too much
conceptual baggage, only to note later that it's largely irrelevant now.

It's actually a relatively simple model, when you focus primarily on the data
structures.

------
ed
If you're interested in the Git internals, I'd highly suggest reading John
Wiegley's "Git from the bottom up":

[http://www.scribd.com/doc/6377254/Git-from-the-bottom-up-
by-...](http://www.scribd.com/doc/6377254/Git-from-the-bottom-up-by-John-
Wiegley)

~~~
timf
Here is the unencumbered and original link for that:

[http://www.newartisans.com/2008/04/git-from-the-bottom-
up.ht...](http://www.newartisans.com/2008/04/git-from-the-bottom-up.html)

------
medearis
I really appreciated your write up as a primer on git. Thanks for writing it.
One issue I have with it, though, is that the part focusing on Pushing and
Fast Forward Merges is either vague or incorrect and led me down some
confusing paths. I'm specifically referring to the part where you claim "one
common problem is when you do development on a branch and the branch changes
on the remote repository as well... if you pull master from the remote
repository, you will get a warning, and if you force the pull to go through,
you will lose commit "

First off, a fetch will never result in a fast forward, since it is just
modifying remote references, not merging local references. If you fetch in
this scenario, it will not cause an error or you to lose your commit. It just
updates the remote reference. You can then merge, resolve any conflicts and
you're set. Doing a pull is just doing these two steps as one -- i.e. a pull =
fetch + merge. After merging, you can push back.

~~~
cduan
Thanks for pointing this out--this is either a new feature since I wrote the
tutorial, or I didn't get it right the first time around. I think it is
correct now.

------
ams6110
This is a good guide for someone getting started with git, but does not really
explain why you might want to use git instead of some other version control
system, such as svn. The title of this work implies it's something more than
an introductory tutorial, but that's really all it is.

~~~
cduan
I appreciate the comment. To be fair, this was intended to be an introductory
tutorial--it was written to teach Git to a friend of mine. Its purpose was to
introduce Git in terms of underlying concepts rather than as recipes of
commands, as most tutorials only provide. I'm not particularly of the view
that "understanding" is the province of experts; novices are perfectly capable
of grokking a system, given proper instruction.

~~~
Batsu
I struggled with svn when I first started out with version control for this
reason. I often found things explained as "this is how you do it" or "What if
you want this? Type this!" which doesn't tell me anything unless I'm asking
the correct question. I found that understanding branching was extremely
important to understanding how the system works as a whole, but perhaps that's
just when everything clicked.

~~~
triplefox
I think many developer tools - and perhaps Unix-style tools in particular -
suffer from this problem of skipping past concepts to syntax. There's an
inherent expectation that you aren't a user who wants just the "shallow"
common-case uses, but instead are going to go through a rite of passage where
you learn the ins and outs of all the concepts the tool uses, make it part of
your daily life, and piece it together with the other small powerful tools
into some conglomeration that solves your problem.

This is great for developers, but bad for end-users, as a lot of users will
run away before learning new concepts(they're busy enough already), while
others will take a macho posturing attitude towards it and look down on the
people who ran away. The community gets polarized. Git exemplifies this kind
of thing, for better or for worse.

It's not a huge surprise that so many developers have switched from Linux to
OSX, since the latter has made many more provisions towards the newbie end-
user; it indicates that most developers don't want to take on this kind of
burden, at least not all the time.

------
rue
Small correction, `git add -a` adds untracked files, too. `git add -u` does
not.

