The book Pro Git says that the staging area is just a list, or index, that says which files will be committed when a git commit is done, and now the name index is more commonly known as the "staging area".
But if we modify the file foo.txt that is already part of the repo, and use git add foo.txt to stage it, and modify the file again, now the file is both "staged" and "modified" (as seen in git status), and if we commit, the "staged" version will go into the commit. The second edit won't go in.
So how can the "staging area" keep track of what the first edit was if it is just an index -- a list of files?
Index is a view of your working directory that is ready for commit. It can be seen as a pre-commit state and is not as simple as a "list of files". When you do git add, the file (with the change) is added to the index and the newer changes will not be see until you add them too.
The index is like an out basket of completed work. At any point you can add a (part) completed file to that out basket and it will replace the previous copy with your current copy, so that when you finally decide to commit it will use the contents of that out basket (the current index) to create the commit.
In addition your earlier add will have create a blob object within the repo that can be found if required via the various logs. After a while (30 days+) it will disappear with gc.
It's an index but to a list of modification trees, not files directly. See the different type of objects git handle.
来源：https://stackoverflow.com/questions/12138207/is-the-git-staging-area-just-an-index