A git Primer | Hacker News Reader

A git Primer

danielmiessler.com

101 pointsdanielrm2619 comments

The primer says "The git branch command lets you create a new branch of your project. It creates a new commit with a new pointer label pointing at it." which is not correct. When a new branch is created it just creates a new pointer to the commit which one branches off from, there is no new commit made automatically.

The best description of git branch that I've heard so far is: "git branch is File -> Save As for your current branch"

That's a pretty good analogy, although you need to remember that a plain git branch is like a File -> Save As that doesn't keep the new name of subsequent File -> Save's

So like "File->Save As Copy" from Photoshop. Makes sense.

One need to be careful while using an analogy. Though at the outset it looks like it explains the branching behavior of 'git' it ain't so. Say I have opened a File and do a File->Save as on a directory mounted from an external storage (say mounted via NFS ). In such a case the file contents need to copied to that storage and there are two copies of the same content. But with 'git' branching that is not the case at all. When you create a branch you just create a new reference to a commit and you start from there, nothing more than that.

Maybe you have don this for brevity, but git branch does not create a new commit.

"The command’s second form creates a new branch head named <branchname> which points to the current HEAD, or <start-point> if given."

So after a git branch command, the test branch still points to the same commit as HEAD.

You have to make an additional commit for them to diverge.

If you know someone looking to get up to speed on Git, I highly recommend Git Immersion: http://gitimmersion.com/

Thanks! That looks like a really helpful working introduction to git. I'll probably start recommending it to git newbies.

I've had to get quite a few people up to speed on Git. What I've found is that for most CS-oriented people, beating around the bush is really just getting in their way. If you create the correct mental model for them, much of git becomes self evident. This isn't easy and takes a couple of days of intermitent whiteboarding but everything 'clicks' soon enough.

Big things:

Explaining that the object name (d56abc..) is really a SHA1 hash of all the contents. Git then uses this name to uniquely identify Git Objects.

Git Objects consist of: blob (file), tree (directory), commit (pointer), tag (well.. its a tag..). When you do a "git checkout" you interact with commit objects. When you do a "git ls-tree master ." you are looking at a tree object.

Branching is done by putting the following in .git/refs/heads/branch_name: d56abc..

And a branch will always just point to a commit object.

Finally, the working directory is of very little concern to git. It has handy functions to drop some of its stuff there for you and it can tell you some differences between its HEAD and your files, but really Git begins at the Index.

+ Lots of little things.

Edit: It is always fun to do a quick 'echo "dbc123.." >> .git/refs/heads/new_branch' and show someone that that is all it takes. It really quickly shows how not-scary git is. There is a ton of complex technology that enables its awesomeness but it is a relatively simple system.

The first section shows "git diff" as the command but shows output from "git status" below it with the only mention of "git status" in the entire post buried at the very bottom.

Fixed, thanks.

git status is very helpful in understanding the git because it shows you the differences between the working directory, index, and previous commi, index, and previous committ.

The first commit is missing it's 't', which it looks like the second one stole.

EDIT: Actually, you just have a copy-paste error.

Thanks for this. I was beginning to think git was for gits only.. this and also the quote from Linus corrects my assumptions..

Phew. Thought this was going to be another explanation of the movie Primer using git.

Cool. I've been looking for a more visual git introduction.

You might be interested in A "Visual Git Guide" as well.

http://marklodato.github.com/visual-git-guide/index-en.html

This is a pretty good guide, but it's marred by one major error:

"the index is your staging area where things go after using git add before they get committed."

That's not right. The index is where things go after MAKING EDITS IN THE WORKING DIRECTORY before they get committed. (What does "after using git" even mean?)

I think you read that `add' as an `and'.

It's "after using `git add', before they get committed", which is correct, the `git add' command adds a file to the index.

Oh. Right. Duh.

Reply on news.ycombinator.com