How does Git's concept of the Index improve or change your workflow?

Question

I've been trying to use Git on my personal projects for almost a month now.

I have a pretty good understanding of the basic set of commands and while its user experience isn't awesome, I still find myself liking Git more than the other VCS's I've used in the past.

However, one concept that I still don't think I have "gotten" is the real purpose of the Index. I have this feeling I'm not taking advantage of some benefit it is intended to bestow.

What is the purpose of having a staging area? Coming from SVN land, I'm so used to treating my working copy as my staging area and my snapshots for my commits being taken from this.

So, my question is:

What does this extra level of indirection give you? How has the Index improved or changed your normal workflow? Can you provide any scenarios where having the Index has allowed you to do something that would have been troublesome to do without it?

Answer 1

Speaking personally, I'm undergoing a massive merge conflict at the moment, and I'm having to fix the items one by one. In this case, I can perform a 'git add' on the files that I've merged, and still keep a separate track of the ones that I need to fix.

Once I've gone through that, I can execute test compiles and then re-add any additional changes that are needed, before I commit to the repository.

Answer 2

There're definitely times when I start working on a feature or a bug fix, and then notice a quick typo or some other tiny (perhaps one-line) thing to fix. Instead of dropping all my work, or even using git stash, I can just commit that just that tiny change via the index; all my other work is still there, but now the commit is more specific: it only shows that small fix, instead of getting buried in dozens of other lines of changes. It's made for a much cleaner history, which makes it easy to search logs for changes since they're not mixed in with other commits.

In the event of (complicated, large) merge conflicts, it's also nice to be able to add each change I make to the index, so I know what conflicts I've fixed and which ones are left to deal with.

Answer 3

Sometimes I'll do a 'git cherry-pick -n' or 'git merge --squash' to pull in a bunch of changes from a foreign branch then I'll unstage all those changes and use git interactive add (git add -i) to stage only the pieces I want. You can even stage select "hunks" of a diff and leave the rest in a changed state (great for de-convolving things that should have been seperate commits).

Also great when you are editing a whole bunch of files but you decide you really ought to commit all the files related to X as a single commit before you go any further, so you just stage those, commit and keep working on the other files.

I also like the way the staging area works with merges to show you what didn't get staged automatically. Sure, the index area isn't strictly necessary for this but I find the default behavior of diff showing you a diff of only the non-index items to be useful so you aren't bothered with seeing the stage stuff unless you use diff --cached.