[UnoriginalGuy]

Unfortunately you fell right into the trap he said everyone trying to explain Git does. The first paragraph is complete nonsense unless you already understand it.

You first call it a staging area and then you clarify with an "index," but you never clarify what an index is?! The second paragraph doesn't improve the situation much.

Ultimately I think there is a language breakdown here. People who explain Git seem to be unable to do so without using Git-language, and it is very difficult to understand the Git-language without understanding how it is used.

So therefore it is a chicken/egg problem. You somehow need to know the language to understand Git, but to understand the Git you need to understand the language.

PS - I know you're trying to help; it is just one of those things where I am not even sure it can be explained in that way.

[philwelch]

I'm not saying it's an "index" to clarify what "staging area" means, I'm saying "index" is a synonym for "staging area" so if he runs into the word "index" somewhere, he knows it's just a different word for the same concept. For Christ's sake, there's nothing magic about the words, they're just names for something. If you didn't know what a dog was, and I said "a dog (aka a canine) is a domesticated animal related to a wolf", I'm not expecting the word "canine" to add anything to the explanation, I'm just throwing it in there in case you run into someone else who says "canine" instead of "dog", just so you know that in both cases they're referring to the same type of thing.

In any case, a staging area only makes sense in the context of trying to create a commit, and I think I did usefully define what a commit is. Maybe that part should have come first.

[OmegaHN]

I suppose you have to know the general idea of a Version Control System (VCS) first before you can understand how Git does version control. I'll try my hand at it.

A Version Control System is a software system that uses files to save different versions of your source code (really, it can save any file, but it works best with source code). The system also lets you revert back to an old version of your code, so you can try something radical out on your code knowing that you have a safe version tucked away in your version control system.

A 'commit' is when you tell the VCS to take a "snapshot" of your files and then save that in its system. Git implements 'commits' with three-location system: the working index (the files on your computer), the staging index (Git's log of what files you want to change), and then the actual commit index (where all the versions are saved). When you stage a file, you tell Git to add the name of that file to it's internal log, telling Git that you want that file to be saved in a version. After you have told Git what files to save (by "staging" them), you can commit (with 'git commit') to save that snapshot of your staged files. Later on, you can revert to the snapshot through git commands.

Hope this helps!