

A git Primer - danielrm26
http://danielmiessler.com/study/git/

======
sateesh
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.

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

~~~
bostonvaulter2
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

~~~
sateesh
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.

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

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

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

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

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

~~~
danielrm26
Fixed, thanks.

------
zheng
_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.

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

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

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

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

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

------
lisper
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?)

~~~
LukeShu
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.

~~~
lisper
Oh. Right. Duh.

