When your project is under the care of a version control system, you edit in your working directory and commit your changes to your repository for safekeeping. Git works similarly but inserts another layer, the index, between the working directory and the repository to stage, or collect, alterations. When you manage your code with Git, you edit in your working directory, accumulate changes in your index, and commit whatever has amassed in the index as a single changeset.
You can think of Git’s index as a set of intended or prospective modifications. You add, remove, move, or repeatedly edit files right up to the culminating commit, which actualizes the accumulated changes in the repository. Most of the critical work actually precedes the commit step.
Tip
Remember, a commit is a two-step process: stage your changes and commit the changes. An alteration found in the working directory but not in the index isn’t staged and thus can’t be committed.
For convenience, Git allows you to combine the two steps when you add or change a file:
$ git commit index.htmlBut if you move or remove a file, you don’t have that luxury. The two steps must then be separate:
$git rm index.html$git commit
This chapter[9] explains how to manage the index and your corpus of files. It describes how to add and remove a file from your repository, how to rename a file, and how to catalog the state of the index. The finale of this chapter shows how to make Git ignore temporary and other irrelevant files that need not be tracked by version control.
Linus Torvalds argued on the Git mailing list that you can’t grasp and fully appreciate the power of Git without first understanding the purpose of the index.
Git’s index doesn’t contain any file content; it simply tracks what you want to commit. When you run git commit, Git checks the index rather than your working directory to discover what to commit. (Commits are covered fully in Chapter 6.)
Although many of Git’s “porcelain” (higher-level) commands are designed to hide the details of the index from you and make your job easier, it is still important to keep the index and its state in mind. You can query the state of the index at any time with git status. It explicitly calls out what files Git considers staged. You can also peer into the internal state of Git with “plumbing” commands, such as git ls-files.
You’ll also likely find the git diff command useful during staging. (Diffs are discussed extensively in Chapter 8.) This command can display two different sets of changes: git diff displays the changes that remain in your working directory and are not staged; git diff --cached shows changes that are staged and will therefore contribute to your next commit.
You can use both variations of git diff to guide you through the process of staging changes. Initially, git diff is a large set of all modifications, and --cached is empty. As you stage, the former set will shrink and the latter set will grow. If all your working changes are staged and ready for a commit, the --cached will be full and git diff will show nothing.
[9] I have it on good authority that this chapter should, in fact, be titled Things Bart Massey Hates About Git.