|
|
|
|
|
by lisper
4654 days ago
|
|
Great article. Just one rather glaring omission: only a single mention of the index, and that only in passing. I have used git for years, and I still don't understand what the fleeping index is supposed to be for. What can you do with the index that you can't do with a branch? And why is it called the index? (And why is it git add -a but git commit -A? Or maybe it's the other way around?) |
|
The index is a staging area for your commits. When you use `git add`, changes in the working directory are staged (prepared) for the next commit. If you pass the `-a` flag to `git commit`, Git will stage all changes to files that it is already aware of. (Recall that new files are untracked and must be manually added to the index the first time they're committed; `-a` won't add those files because Git doesn't already know about them.)
Why have a staging area instead of just creating a commit directly from all the changes in the working directory? It's basically a sanity measure for organizing commits if you're ever anything less than a perfect developer. If you make a bunch of changes and later realize that there's more than one "unit of work" represented in those changes (however you choose to define those units), you can selectively add files to the index to create commits that make sense. You can even use the interactive mode of `git add` to selectively stage changed sections within a single file. If you care about the benefits of sensible commits -- bug hunting with bisection, ability to run `git revert` to undo a logical unit of work -- then the index is your friend.
A few random pages on the index that I pulled up:
[0] http://www.gitguys.com/topics/whats-the-deal-with-the-git-in...
[1] http://git-scm.com/book/en/Git-Tools-Interactive-Staging