Two-tree architecture

Is used by lot of other version control systems . In this we have a repository and a working copy, our working copy begins with the top of our project directory and below of that might be one or thousands of file and subfolders. Repository may also has a set of files and subfolders in it. When we want to move files between the repository or the working copy, we

 check out 

the term that we use to pull the working copy from repository into our working directory, and once we finish making our changes we push those changes back to the repository. Now what happen I checkout the latest code from the repository, I make changes in my local machine and saved, but these changes are not done into repository or say they're not yet committed to the repository i.e repository is totally unaware about the changes I have made. That's means code in repository is different from the code in my machine So my working copy looks different from the repository. Both are saved, it's not like I haven't saved the files, I've done that. They just aren't saved and tracked in the version control repository.

Where The issue arise now.

Now if the repository is a shared repository, and a team of developer working on it, they may commit their changes to the repository. And if I haven't checked out a copy recently to get those changes, then my working copy doesn't have their changes.
So once again the repository and the working trees will not have the same data in them. and this could a big drawback when a large team of developer working on it.

Three-tree architecture

However Git uses a three-tree architecture. It still has the repository and the working copies, but in between is another tree known as staging index.
Though it is possible to go commit directly to the repository and skip the staging step. But it's important that we understand that this is a part of the architecture of Git, and it's a really nice feature.

Now we can make changes to twenty different files in our local working copy. and only commit, commit five of these as one changed set.

So what I am going to do is I am going to put those on the staging index, add them to the staging index, get those five files ready to go, and as soon as I am satisfied that they are ready, I will commit those five files in one changed set to the repository.

The other five files are still saved in my local working tree, but they never got added to the staging index or to the repository.

It's possible to pull them from the repository to the staging index, from the staging index to the working directory, usually that's not what we do.

Normally we pull from the repository down to the working directory. and in all this process staging index get updated too.

In Brief

We have our working copy, where we have our changes that we've made, and we've saved, and saved to our hard drive, but we have not yet committed them to the repository, we haven't told Git to make this a changed set and to track it.

Then we have the staging index, which is where we prepare things, we stage them for the commit, and then after they've been staged, we commit them to the repository so that they are permanently tracked and they now have a commit with a message attached to them.

The more you practice the more you will know the depth of Git architecture

Thanks