Introduction to Git Index
GIT is one of the most commonly used distributed version controller DVCS among the programmers because of its dynamic nature and vast tool availability to handle the versions. It is known to be the first-ever feature to be added to Git. Index as the name suggests, like any contents of a book, it also maintains the staged changes or we can say indexes the changes that are sent to stage using git add.
In technical terms, Git Index will maintain Tree (can be related to the directory structure or folder in Unix) and blob (can be related to files and other associated content inside the directory) Git objects.
In git DVCS we have the source code on the server which acts as a central repository but along with that, we have it as a local copy or we can call as a local repository on working machines. So even if there is a failure at the server level we can mirror back the local working copy to the server when it is restored. So basically when we work on a branch, commit our changes, it will send the changes to the local repo. We need to use PUSH to send the changes to the server repo. GIT Index is something that comes in between local repo and working directory and it is the one that decides what needs to be sent to the local repo and in fact, it decides what needs to be sent to the central repo.
Detailed Explanation of GIT Index
Please refer below pic to get a more detailed idea.
Here repository in the sense local repo or local copy. From the above pic below are the inferences:
- when we start working on an existing file or create and add a new file and save them then git tracks them and mark them as untracked files. We can clearly see them in the below screenshot. I have totally four files in test_git_tools branch and if I give git status the I can see all the files have been modified state.
- If you observe the above screenshot it presents us with two options as shown So, in fact, our git is suggesting that it had tracked the changes in the working directory but it is up to us whether we want to strongly track it by sending it to the staging area by using “git add -u” or discard the changes and leave the tracking by using “git checkout”.
- Once we add the file to the staging area than when we apply to commit then the changes that are staged will only go to the local repo. Unstaged changes remain.
- Once we have added the content to local repo then we can PUSH to submit the changes to server repo.
Above the sample screenshot which shows that there were two files that were indexed and they were committed. Remaining two files were tracked but unstaged so did not commit. But why do we require staging or indexing? Cant, we just directly send the unstaged changes to local repo?
Yes, we can bypass staging and directly commit our unstaged files to repo but doing like this will actually distort the purpose of a version control system. This may be feasible in small projects or enhancing projects but in a fresh project doing like this can cause cumbersome.
Indexing is one of the most critical stages in the development of a project. When we try to develop a project we basically prepare an algorithm on the coding module and prepare a draft code where we are uncertain about some aspects and needs further evaluation. Also, you may decide to add some extra features, or we may add certain optimizations, etc. In these cases, we don’t want to completely discard the thing we developed. By indexing the developed code we can always track the difference between staged file and unstaged same file and clearly get more ideas on different versions. Let us look at this in the below screenshots. From the above screenshot, we can see all the red marked files are untracked. I will add the file to staging which turns the color indicator to green as shown below.
Now i will add one movie name to the staged file forien_movie_list file and perform git status. It looks like as below:
we can see that we have twp versions of the file orien_movie_list one indexed and other untacked. We have a very useful indexing tool called difftool with which we can track the changes to both versions of the file by configuring it with your git.
Now lets the programmers decided that he does not want to keep the new change and doesn’t want it to be staged. Then instead of git add command he can use checkout to discard the unstaged change.
You can clearly see from above the red modified file has been discarded. This you can validate by looking at the content of the file as well.
Now similar to the way programmer had added his content to the staging area, he can upstage them as well if required. Basically indexing is providing plenty of opportunity to the developer to work on his code by giving its control to him. To achieve upstaging the popular tool used reset command.
You can see from above that the files we indexed (in green) have been added again to the unstaged area. Here I have used HEAD with reset the command which says that the latest content that was added to the staging area to be reset (here I have used four files earlier to index, so they were unchanged (red)).
There is also an ls-files option available with git which will list the files in the index. In index basically, full tree and blob information will be available. So when you add something to the stage then it starts closely monitoring that file. We can see this with –debug command along with ls-files. In the below screenshot, we can see that we have two files in the staging area and two files as unstaged. Now when I gave git ls-files -s it will give all the available blob (four files) inside the tree as shown below. But we have added only two files to the staging area and two can use –debug to validate this.
we can see from the below screenshot which files have been staged by the value of ctime,mtime, dev, etc.
Git Index is the most important area when we deal with Git DVCS. There are plenty of commands and tools available of which I have used some in this article to play with indexing and for a serious developer this nothing short of the boom.
This is a guide to Git Index. Here we discuss the introduction and detailed explanation of the GIT Index with the help of respective screenshots. You can also go through our other suggested articles –