. This is the third post in my Understanding Git series so be sure to check out the first two ( Data Mode l and Branching ) before proceeding with this one There are three areas where file changes can reside from git’s point of view: working directory, staging area, and the repository. Git areas When you work on your project making changes you are dealing with your project’s . This is the project directory on your computer’s filesystem. All the changes you make will remain in the working directory until you add them to the (via command). The staging area is best described as a preview of your next commit. Meaning, when you do a , will take the changes that are in the staging area and make the new commit out of those changes. One practical use of the staging area is that it allows you to fine-tune your commits. You can add and remove changes from staging area until you are satisfied with how your next commit will look like, at which point you can do . And after you commit your changes they go into directory where they are saved as commit, blob and tree objects (as we saw when we looked at git’s ). working directory staging area git add git commit git git commit .git/objects data model Although it is often useful to think of staging area as some real area (or directory) where git stores changes (like it does in ) this is not entirely true. Git doesn’t have a dedicated staging directory where it puts some objects representing file changes (blobs). Instead, git has a file called the that it uses to keep track of the file changes over the three areas: working directory, staging area, and repository. And when you add changes to your staging area, git updates the information in the index about those changes and creates new blob objects, but puts them in the same directory with all the other blobs that belong to previous commits. This maybe sounds a bit complicated but actually it isn’t, so let’s go through a typical git workflow example to display how git uses the index. .git/objects index .git/objects Let’s say we are on a branch and there is also a branch in our repository. If we do master feature git checkout feature three things are going to happen. First, git will move the pointer to point to the ref (branch). To make things more simple we will display only the last commit on the branch. HEAD feature feature Git checkout first moves HEAD to feature ref Next, git will take the content of the commit that is pointing to and add it to the index. feature Git checkout updates the index As we mentioned earlier is not a directory but a file, so git is not actually storing objects (blobs) into it. Instead, git is storing information about each file in our repository: index — is the time of last update mtime — name of the file file —file version in working directory wdir —file version in the index stage — file version in the repository repo File versions are marked with checksums (if two files have the same checksum then they have the same content/version). And finally, git will make your working directory match the content of the commit that is pointing to (it will recreate the content of your project’s directory using tree and blob objects). HEAD Git checkout makes you working directory match HEAD So, after checkout, every file will have the same version in the working directory, staging area/index, and the repository. If we now edit our file index.php Updating index.php only affects the working directory those changes will affect only our working directory. But if we now run git status git will first update the index with the new working directory version for index.php Git status updates the index and then it will see that has different versions in working and staging directory. index.php Git status sees that index.php has different version in working directory and staging area So, git will tell us On branch featureChanges not staged for commit:(use "git add <file>..." to update what will be committed)(use "git checkout -- <file>..." to discard changes in working directory) modified: index.php no changes added to commit (use "git add" and/or "git commit -a") that there are changes in our working directory which are not in our staging area (and therefore won’t be included in our next commit at this point). So let’s add our file to the staging area by doing index.php git add index.php Two things are going to happen. First, git will create a blob object for our file and store it into directory and second, it will again update the index. index.php .git/objects Git add creates blob file for index.php and updates the index If we now do git status git will see that version in staging area matches the working directory version but doesn’t match the repository version index.php index.php has different versions in staging area and repository so git will tell us: On branch featureChanges to be committed:(use "git reset HEAD <file>..." to unstage) modified: index.php that is now staged to be committed. index.php And now when we commit our changes git commit -m "Adding some code magic to index.php" git will: create a new commit object and tree object (and hook them up with the blob object that was already created with ) git add move the ref pointer to the new commit feature update the index. Git commit creates commit/tree objects, moves the feature ref, and updates the index And now our file again contains the same versions in all git areas. index.php And that is it — the mysterious git index. Now that we looked at it, it is not so complicated but it is vital to know in order to understand the commands that operate on the index (add, checkout, reset …). In writing this post I heavily used Scott Chacon’s so be sure to check it out. lecture
