
Git in six hundred words - monsterix
http://maryrosecook.com/blog/post/git-in-six-hundred-words
======
NelsonMinar
"You go to commit some code to a public repo. The maintainer scolds you for
using merges instead of fast forwards."

"You decide to bring in some more code from the public repo. Here is a 6000
word essay on what rebase means."

"You try to look at an old version of the code. Suddenly you are in ‘detached
HEAD’ state. The End."

I love git, but simple intros like this hide all the confusing complexity and
awkward UI that quickly comes to the forefront when using git for everyday
work.

~~~
reuven
I teach courses on Git, and I couldn't agree more. _Many_ of my students have
been told that Git is simple, and they just need to know 10 commands. Or they
can think about it like SVN. Or that they should push, pull, and that's about
it.

Which has the effect of (a) making them fear Git, (b) making them feel like
they'll never figure it out, (c) and convincing them that they're always on
the verge of losing data. I've literally had students at the start of my
course refer to Git as "that system that makes me lose files."

Once I teach people about Git's objects and data structures, things suddenly
become much more obvious to these people. Git becomes less of a mystery.

I'm not saying that Git is easy for people to understand or use, because it
isn't. It has a steep learning curve -- one which I think is worth the effort.
But I think that it does a disservice to Git newbies to try to summarize all
of Git's functionality in a short essay, and then proclaim, "See? There's not
that much to learn here!"

~~~
NelsonMinar
I would be grateful for your course. I've used git now for 3+ years and still
don't feel like I understand Git's objects and data structures. Maybe it's
because I didn't finish my PhD.

~~~
reuven
Finishing a PhD gives you bragging rights, but it doesn't make you any
smarter! (Believe me, it took me 11 years to do mine... and I've got the bills
and emotional scars to prove it!)

I might start to teach courses online at some point, but I'm right now so busy
with in-person classes in Israel and China (with a bit in Europe probably
happening soon) that I haven't had a chance to consider it. But hmm, maybe...

Meanwhile, see my above reply with some suggested resources to learn about and
understand Git. I hope that they'll help.

------
js2
This is perhaps too few words to elucidate git. I appreciate that Ms. Cook
links to other articles on her own site that go into much greater detail.
However, I still think the best self-contained and relatively brief
explanation of Git is "The Git Parable."[1]

[1] [http://tom.preston-werner.com/2009/05/19/the-git-
parable.htm...](http://tom.preston-werner.com/2009/05/19/the-git-parable.html)

~~~
nightpool
In fact, the Git Parable specifically addresses this articles approach to
teaching git in the introduction:

"Most people try to teach Git by demonstrating a few dozen commands and then
yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may
leave you with the ability to use Git to perform simple tasks, but the Git
commands will still feel like magical incantations. Doing anything out of the
ordinary will be terrifying."

Makes the 600 words achievement seem less impressive, if you put it in the
context of existing git education.

~~~
billforsternz
I can't agree with this. The 600 word article explicitly does not simply
demonstrate some commands and go "tadaaaa". Quite the contrary, it
demonstrates some commands and explains how they work, a very impressive
achievement for something so terse.

------
binarycrusader
And here, perfectly illustrated, is a reminder why I don't like using some
source code version control systems. I don't want to understand the precise
implementation of my source code control system, and I don't personally
believe that I should have to for effective use.

I realise this is likely an unpopular opinion, but I would challenge you to
reply with justification rather than inevitably downvoting me into oblivion.

One of my software development mentors (a long time mechanical engineer who
has done UNIX OS development for 20+ years) often has this as his email
signature and I think it's rather apt in this context:

    
    
      Civilization advances by extending the number of
      important operations which we can perform without
      thinking about them.
    

With that said, I'm not advocating complete ignorance of _how_ a version
control system "works", I just find the philosophy of "you must learn the
internal data formats and workings of this system to use it effectively" more
than a bit distasteful.

~~~
ackalker
Just how does using `git init`, `git add`, `git commit`, `git push`, `git
merge`, `git pull` force one to know Git's implementation details?

Even thinking of Git as a security camera watching your shop (working tree), a
VCR (record, forward, rewind history), a videotape copier (branching, pushing)
and video editor (pulling, merging) wouldn't be too far off the mark, without
the need for any reference to Git's inner workings.

Sure, a lot of Git talk mentions SHAs, trees, blobs, etc., but they could just
as well have been brownies, blurfls, gizmos or whatever, as long as the
practical context in which one needs these things is clear. Branches, tags and
remotes are still the most useful top-level concepts, with no need for knowing
their implementation details.

Only when one needs to do really low-level stuff like efficient import/export,
history rewriting (ugh) etc. does one need to know a little more about _how_
Git works. Many people have used Git for years without knowing anything about
the plumbing beneath its porcelain.

~~~
burkaman
With that usage, you don't need to understand the implementation. But in my
experience of using Git without really understanding it, there is about a 90%
chance of destroying your repository when you try to revert something. I have
never had this problem with any other VCS.

I'm sure simple reverting is super easy once you know what you're doing, but
you need to know what you're doing.

~~~
stream_fusion
Reverting a commit is trivial. There is zero opportunity of destroying a repo.
From my notes,

# revert a commit

git revert dd61ab32

~~~
burkaman
Well that does look simple, but first of all, it doesn't really revert a
commit. It makes a new commit to cancel out the old one, or something. Not
intuitive, unexpected results if you don't know what you're doing.

But the situation I got into was when I did something stupid and just wanted
to undo it. Let me go back to an hour ago before I screwed up my project.
That's not revert, it's reset, but reset only reverts the commit history, you
really want reset --hard. And of course you need to be pointing to the right
place for this to work, and there are other ways for it to go wrong. It might
be hard to imagine if you're at all competent with Git, but trust me when I
say you can get yourself into some very frustrating scenarios if you just
Google "undo push" and blindly follow the instructions.

Here's another simple scenario: I'm working on a bug, my friend fixes it first
and pushes his version. I just want to pull his changes and throw away
whatever I was working on. Ok, so I find this:
[http://stackoverflow.com/questions/1125968/force-git-to-
over...](http://stackoverflow.com/questions/1125968/force-git-to-overwrite-
local-files-on-pull?rq=1)

Look how many different methods there are. Look how many warnings of "THIS
WILL DELETE ALL UNTRACKED FILES" there are. Why is this necessary? I could
rant for a while longer, but this stuff is so incredibly unfriendly and
frustrating to newcomers. I don't want to think about this stuff, I just want
to go back to the code.

------
bgilroy26
This is a cool essay! It's very approachable. I would really like to
understand git under the hood one day, but I'm intimidated by how much it does
with such a small memory footprint.

My group project partner and I were having the toughest time with git last
night. I thought we were all ready to walk out the door and then we ended up
monkeying around with it for an hour and a half.

The atlassian visual guides really helped:

[https://www.atlassian.com/git/tutorials/](https://www.atlassian.com/git/tutorials/)

They're great for people who know the names of all the git commands but who
are still thrown off in really basic situations, ie 'Is it merge master? Merge
origin master? Merge origin/master? Why does it say already-up-to-date?'

------
iconjack
What git needs is a simple undo command, as in

    
    
        git undo
    

and it just undoes whatever you just did. There seems to be a way to undo
pretty much anything, but I usually end up googling and deciphering the likes
of

    
    
        git reset HEAD hard -f --now origin/master --no-rebase %${%&`+'${`%&NO CARRIER") 
    

Then when that goes wrong, you're in real trouble and left scratching your
head at git's error message.

~~~
kelnos
Hmm, the reflog usually (always?) provides all the info you need to undo the
last action. I wouldn't be surprised if it were possible to build a "git undo"
command on top of that. The fact that no one has yet done so is a great
illustration of your point, though.

~~~
kragen
The reflog just lets you undo commits (whether created by `git commit` or
rebase or merge or whatever), while actions like `git reset`, `git checkout`,
`git add`, `git gc`, and `git rm` cannot be undone with the reflog.

------
jordanpg
There is some subset of all VCS software that contains the handful of commands
that 80% of coders need 80% of the time. Conceptually, these commands are very
nearly isomorphic for individuals making changes to files by themselves.

These paragraphs do indeed cover those commands for git, although I can't see
why this presentation is particularly useful, even for a beginner. It's just a
condensed HOWTO that doesn't actually explain what it's doing.

Newcomers would be better advised to sacrifice the 30 minutes and read the
first three chapters of the storied git book: [http://git-
scm.com/book/en/v2](http://git-scm.com/book/en/v2).

~~~
PuffinBlue
As a new user of Git, I cannot support this comment enough. The Pro Git book
is a fantastic resource that cleanly and concisely outlines the command AND
the conceptual framework upon which Git operates.

I strongly recommend that all new users read at least those first 3 chapters,
but also the very useful chapters on using GitHub - a website that I have
personally found extremely unintuitive to use.

------
ajays
I'm an SVN user, and I'll have to move to git some day, but it's not winning
any points for me :-( . I got bit by it recently. I had cloned a repo, and
then a few weeks later, did

    
    
        % git status
        On branch master
        Your branch is up-to-date with 'origin/master'.
        nothing to commit, working directory clean
    

I assumed the working copy was up-to-date, as git states.... but alas, no. I
had to do a "git pull" to get the latest changes. Why doesn't git tell you
that your copy is out of date?

~~~
scrollaway
Git does not check with the remote unless you tell it to. So "origin/master"
points to what master on origin pointed to the last time git contacted the
origin remote.

To have git contact the remote again, you can do "git fetch origin" (or just
"git fetch"). Then git will tell you your copy is out of date compared to
origin/master, if there's been commits on origin since.

If you commit things, then _your_ copy will be ahead of origin/master, so
origin/master is what is out of date and you need to git push:

    
    
        ~/dotfiles % git status            ✓✗ master:c024cb4 - dotfiles 
        On branch master
        Your branch is ahead of 'origin/master' by 1 commit.
          (use "git push" to publish your local commits)

~~~
mattmanser
Yeah, but your branch isn't up-to-date is it? It's bad wording.

~~~
djur
It's up to date with origin/master, which is the local copy of the remote
master. 'git fetch' updates those local copies. 'git pull' does a fetch and
then merges origin/master into master.

It makes sense when you consider that there are other ways that origin/master
could be updated. You could apply commits that someone emailed you (a common
workflow in the Linux kernel that git was designed to support), or someone
could push commits directly to you over SSH or the filesystem.

------
csomar
Fast-forward 5 years into using Git, I learned that _git add_ and _git commit_
is all you need to know to get started. I learned everything else, on the job
and by need.

\- _git push_ when I needed to take work to Github

\- _git checkout_ when I needed to move between branches

\- _git merge_ when I needed to merge someone else work into master

\- _git cherry-pick_ I needed this to take commits from a non-fork to my
project

\- _git bissect_ Debugging a bug introduced between releases

I also learned to use Github tools, SourceTree, the Command-Line and
Bitbucket. If you want to learn git, just make a commit. Everything else will
be mastered down the road.

------
msamwald
For me, the hardest thing about learning Git is the lurking feeling that I
have to learn it because it has become an unavoidable fad, not because it is
the best approach to version management for most common use-cases.

~~~
AndyKelley
I think your attitude is completely reasonable, and I'm with you on your
skepticism. However I am pleasantly surprised that, for once, a software fad
lines up with what is actually technically superior. Linus knows how to design
software correctly.

~~~
recursive
Debatable. In the two dimensional space of UI quality vs adoption, git seems
to be way out on a frontier.

------
Ellipsis753
The page is just pure white for about 30 seconds before it loads for me.
(Gentoo Firefox on Linux.) I don't know why but all the items on the page are
positioned off page with "visibility: hidden".

Anyway, in case the author sees I thought they might want to know. And if it
doesn't load for someone here, wait 30 seconds and it probably will.

I can see in the console your fonts are failing to load. Perhaps this is
causing the issue?

------
Cyberis
That was a completely confusing entry. If I didn't already have a pretty good
handle on git, I would be hopelessly confused.

------
chx
[http://www.sbf5.com/~cduan/technical/git/](http://www.sbf5.com/~cduan/technical/git/)

"The conclusion I draw from this is that you can only really use Git if you
understand how Git works. Merely memorizing which commands you should run at
what times will work in the short run, but it’s only a matter of time before
you get stuck or, worse, break something."

------
stevewilhelm
This might be useful for someone who is managing a personal project on Github.

Add a couple of additional developers with 600 words of git understanding
would result in chaos.

------
shocks
I see a blank page.

Is this a joke I don't get?

edit: [https://i.imgur.com/TQxyQES.png](https://i.imgur.com/TQxyQES.png)

~~~
meta-coder
Probably due to HTTPS Everywhere. Try disabling the rule for Fonts.net.

------
DougBTX
Git in six words: content addressable filesystem with linked revisions.

------
zackmorris
Anyone know of a point and click graphical tool for git? I've seen the
branches and merges from the console but if I simply want to take git to a
specific commit hash, it can easily devolve into hours of research.

I believe the problem here is that even though there are only a finite number
of choices (less than a dozen in everyday life) representing what I want to
accomplish, there are countless ways of getting there with commands. I just
don't remember having these kinds of problems with svn, so I think the
difficulty is not conceptual, but due to a poor mapping between the concepts
and the interface.

I'm thinking something like Apple's Time Machine, where you click a commit and
the repo shows up on the desktop as a mounted drive. We could use ordinary
tools to edit the image and when it's unmounted it becomes a new commit (or
something along those lines).

~~~
fsk
SourceTree (by BitBucket) has a decent GUI Git client.

The official github client is trash. The last time I used it was a year ago,
so it might have improved since then.

~~~
niuzeta
Still is.(gave it a try yesterday. Not a lot has changed.)

I do like the git-bash on Windows, though. For some reason I've avoided
installing cygwin.... ever.

------
paulvs
I remember seeing this posted on HN a few months back.

Here's the link:
[https://news.ycombinator.com/item?id=8932737](https://news.ycombinator.com/item?id=8932737)
(see the comments for the correct link..)

I remember liking reading it.

------
mjrpes
I've definitely found git confusing to understand. I've had to write myself a
tutorial to get my head around the concepts and day-to-day workflow:

[http://freetexthost.com/pe020d1b41](http://freetexthost.com/pe020d1b41)

------
morpheous
"It points the master branch on beta at the commit object that the master
branch points at on the alpha repository."

Yes, as clear as mud. This is why I hate git. Why should code versioning be SO
bloody complicated?!. Give me SVN or ( _shudder_ ) CVS anyday.

------
michaelmcmillan
Correct me if I'm wrong, but the first couple of sentences seems wrong. Git
can only be initiated in an empty directory.

Other than that: This is a very short and concise introduction, especially the
merging.

~~~
davess1
Nope, git can be initialized in directories with files in them.

    
    
      ➜  ~  mkdir test1
      ➜  ~  cd test1 
      ➜  test1  echo "hello" > hello.ttx
      ➜  test1  ls
      hello.ttx
      ➜  test1  git init
      Initialized empty Git repository in   /home/david/test1/.git/
      ➜  test1 git:(master) ✗ git status
      On branch master
    
      Initial commit
    
      Untracked files:
        (use "git add <file>..." to include in what will be committed)
    
      hello.ttx
    
      nothing added to commit but untracked files present (use "git add" to track)
      ➜  test1 git:(master) ✗

~~~
michaelmcmillan
I stand corrected, wonder where I got that misconception from.

~~~
mh-
you can't _clone a remote repo_ into a non-empty directory.

from `man git-clone`:

    
    
        Cloning into an existing directory is only allowed if the directory is empty.

------
dsjoerg
i'm just waiting for git to flame out

~~~
flushtwice
Agreed, it's like the perl of vcs. Please go away.

------
morpheous
[https://www.youtube.com/watch?v=UllNDRXR1vM](https://www.youtube.com/watch?v=UllNDRXR1vM)

------
ttty
almost git internals

------
unclesaamm
FWIW, the syntax highlighting is a little overwhelming for me.

------
WorldWideWayne
I am looking forward to a time when memorizing commands seems archaic.

~~~
zedadex
Hear, hear.

