Why is there a staging process in git?

Why is there the staging area between "git add" and "git commit"? I understand the concept, but fail to see the sense in a开发者_高级运维dding files to the staging area before actually commiting. Why not skip this step?

---

The truth is: the index is a staging area. Every SCM has it, but git shows it to you, and uses it effectively.

One main reason is so you don't have to commit your entire working directory. You can move portions of it to the index and commit just those.

For example, you're working on two different things, and now your code looks like

//random code

//bug fix

//new feature

You can stage just the //bug fix line and commit that, and than stage the //new feature line and commit that.

You now have two different commits for each. Later on in testing you realize the new feature commit broke something, you can delete the new feature commit, but don't have to recommit the bugfix

As Dickon Reed noted in his answer, you also gain performance as git commit now only needs to add what is in the index to the commit. It doesn't need to search through your tree to find all the changes.

---

1. git commit doesn't have to check every file in the tree to see if has changed. On a big tree that can be a big time saving.
2. By staging some files (or ever some changes within some files) you get nice fine grained control of what exactly you want to commit and what you do not. For instance, if you spot a trivial bug while part way through a big change you can quickly stage and commit a one line bug fix without all the other changes getting in the way.

---

This is a pure PITA (in my humble opinion). Evidently, most UI tools (actually all I know off, including Eclipse's EGit, Mac XCode, and GitHub client) don't expose this feature.

I understand the notion of partial commit. You don't want to commit everything you have on your file system. But introducing the concept of a "Stage" for it is an overkill.

There are currently 4 stages for your check-in to go through:

1. Your file system
2. The staging
3. your local repository
4. the remote upstream

UI frontends to git do not exposes the staging. They show you all the changes you have. You check the ones that you want to commit and you commit in a single operation.

Possibly, this is an impolmentation detail that got elevated into a UI concept. Instead of a:

commit( X, Y, Z)

you have:

add(X), add(Y), add(Z), commit()

---

You might want to commit only some of your changes. If you fix something you can commit only the relevant changes for the fix.

---

I've just started exploring the wonderful world of DVCS and although I've already sold my soul to git demon but I still have unbiased view. There is some redundancy in idea of staging area however you can neglect staging area entirely (which I did while I was using github client). On the other hand it gives more flexibility so I would say it's unobtrusive redundancy which sometimes can help you a little.

What jumped into my mind is that there are too many terms naming it: cache, staging area, index. Obviously this design decision emerged as aggregation of similar concepts and it has some history under it. My first bet proved to be plausible - I went to Bitkeeper site and found "staging" there (they use it for on-demand branching)

Now I'm guessing that at the time when Bitkeeper was managing Linux sources this feature was misused and instead of creating on-demand branch for several developers it was used just by one developer. And later because this use case proved to be useful Git incorporated lightweight version of "staging area" which is conveniently implemented by providing user interface to "index" or "cache".