转载至http://stackoverflow.com/questions/3689838/difference-between-head-working-tree-index-in-git
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.

They are basically named references for Git commits. There are two major types of refs: tags and heads.
- Tags are fixed references that mark a specific point in history, for example v2.6.29.
- On the contrary, heads are always moved to reflect the current position of project development.

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:
- it tells Git which commit to take files from when you checkout, and
- it tells Git where to put new commits when you commit.
When you run
git checkout refit pointsHEADto the ref you’ve designated and extracts files from it. When you rungit commitit creates a new commit object, which becomes a child of currentHEAD. NormallyHEADpoints to one of the heads, so everything works out just fine.

理解Git工作流程:头指针、工作树与索引
本文深入解析了Git中头指针、工作树与索引的概念及其作用,通过实际场景阐述如何利用这些概念进行代码管理,确保在探索不确定方向时能够随时恢复工作。
5276

被折叠的 条评论
为什么被折叠?



