问题
The following image is Git flow diagram, I'm very strange why Git need to design Index /Stage.
You know the communication between Repository and Workspace is local, it's easy to commit or rollback between Repository and Workspace.
Why does Git need to design Index /Stage ?
Image
回答1:
This is sort of a preview for changes about to be committed. You can, incrementally or in one go, constitute the future commit in this dedicated space, inspect what's in it, and commit only when you're satisfied with its contents.
Some people almost ignore its existence and never use add, relying on -a for their commits to add everything blindly, but this is considered bad practice as it sets up future headaches when, in more complex cases, an understanding of the index will be crucial.
I'd suggest looking at this, among other articles.
回答2:
The files that are staged serves as a display where the committer can see the changes he is about to add to that particular commit. It also helps in typing up git commit -a which is a bad practice as mentioned by @Romain.
Below is one other use-case,
You have changes in a.txt and b.txt but need to perform two individual commits for those files, for whatever reasons(Maybe push a.txt to a different branch and b.txt to a different branch!). Imagine the work to be incurred!
Having indexed file simply makes the life of developers easy ,it is not a blind design decision.
回答3:
Mercurial is an existence proof that Git's index / staging-area is not necessary. Mercurial and Git are equally powerful (at least as far as storing revisions go), but in Mercurial, the work-tree is the staging area / proposed next commit. In Git, the work-tree is irrelevant, and the index is the staging area / proposed next commit.
That said, Git is considerably faster than Mercurial. A lot of this speed is a result of Git keeping its separate index (though a lot is also due to Mercurial's implementation in Python rather than C). So the presence of the index gains Git quite a bit of "go-fast", if you will.
While some people find the separate staging area nothing more than an annoyance, others—as you've seen in other answers—find this separate staging area to be very convenient. In particular, you can stage something—copy some version of a file from the work-tree to the staging area—and then modify the work-tree file further, or differently, such as to add debugging information that isn't in the to-be-committed copy of that file. Using git add -p and git reset -p, you can add and remove specific fixes while leaving the debug sections to exist only in the work-tree.
So this provides two of the motivations for having the index: you can have a staging area that deliberately differs from your work-tree, and Git goes much faster because Git's staging area is already suitable for a commit. (Mercurial's is not ready to be committed: the work-tree must be massaged into the suitable-for-commit form first, and regardless of which language implements the massaging or how much caching you throw at this problem, there will still be some compute effort here.)
Once you've bought into the idea of a separate staging area, that offers a third motivation: now you can create additional staging areas whenever you want, if that's useful for some particular purpose. That's how git stash is implemented, for instance. (It's also involved in git worktree add, although additional work-trees are added as a pair: you get a new work-tree with a new index. If anything, that argues that the new work-tree should be the new index, i.e., that the Mercurial model is better!)
来源：https://stackoverflow.com/questions/54805005/why-does-git-need-to-design-index-stage