What's the difference between HEAD, working tree and index, in Git?
Can someone tell me the difference between HEAD, working tree and index, in Git?
From what I understand, they are all names for different branches. Is my assumption correct?
Edit
I found this
A single git repository can track an arbitrary number of branches, but your working tree is associated with just one of them (the "current" or "checked out" branch), and HEAD points to that branch.
Does this mean that HEAD and working tree are always the same?
A few other good references on those topics:
I use the index as a checkpoint.
When I'm about to make a change that might go awry — when I want to explore some direction that I'm not sure if I can follow through on or even whether it's a good idea, such as a conceptually demanding refactoring or changing a representation type — I checkpoint my work into the index. If this is the first change I've made since my last commit, then I can use the local repository as a checkpoint, but often I've got one conceptual change that I'm implementing as a set of little steps. I want to checkpoint after each step, but save the commit until I've gotten back to working, tested code.
Notes:
the workspace is the directory tree of (source) files that you see and edit.
The index is a single, large, binary file in <baseOfRepo>/.git/index , which lists all files in the current branch, their sha1 checksums, time stamps and the file name -- it is not another directory with a copy of files in it.
The local repository is a hidden directory ( .git ) including an objects directory containing all versions of every file in the repo (local branches and copies of remote branches) as a compressed "blob" file.
Don't think of the four 'disks' represented in the image above as separate copies of the repo files.
They are basically named references for Git commits. There are two major types of refs: tags and heads.
(note: as commented by Timo Huovinen, those arrows are not what the commits point to, it's the workflow order , basically showing arrows as 1 -> 2 -> 3 -> 4 where 1 is the first commit and 4 is the last)
Now we know what is happening in the project.
But to know what is happening right here, right now there is a special reference called HEAD. It serves two major purposes:
When you run git checkout ref it points HEAD to the ref you've designated and extracts files from it. When you run git commit it creates a new commit object, which becomes a child of current HEAD . Normally HEAD points to one of the heads, so everything works out just fine.
The difference between HEAD (current branch or last committed state on current branch), index (aka. staging area) and working tree (the state of files in checkout) is described in "The Three States" section of the "1.3 Git Basics" chapter of Pro Git book by Scott Chacon (Creative Commons licensed).
Here is the image illustrating it from this chapter:
In the above image "working directory" is the same as "working tree", the "staging area" is an alternate name for git "index", and HEAD points to currently checked out branch, which tip points to last commit in the "git directory (repository)"
Note that git commit -a would stage changes and commit in one step.
Your working tree is what is actually in the files that you are currently working on. HEAD is a pointer to the branch or commit that you last checked out, and which will be the parent of a new commit if you make it. For instance, if you're on the master branch, then HEAD will point to master , and when you commit, that new commit will be a descendent of the revision that master pointed to, and master will be updated to point to the new commit.
The index is a staging area where the new commit is prepared. Essentially, the contents of the index are what will go into the new commit (though if you do git commit -a , this will automatically add all changes to files that Git knows about to the index before committing, so it will commit the current contents of your working tree). git add will add or update files from the working tree into your index.
上一篇: 我怎么能分裂一个埋在历史中的Git提交？