Git- Three Stage Architecture
First of all, let us have a look at a two stage architecture Version Control System.
In a two stage Version Control System, we work on our working directory, commit some changes and then push to the repository. Then again, we can pull the changes from the repository (changes which might have done by our colleagues), commit some changes, and again push back the files to the repository.
Till now, it seems very good, but now imagine a situation, when you are working on a project consisting of say 4 files. Now, you have finished working on 2 files, but in other 2 files, you have encountered some bug. In such situation, if you commit changes to the repository, then the other two files containing bug will also be committed to the repository. This is a serious problem!
But git solves this problem by introducing a middle stage called “staging area” in this architecture. Let us have a look at three stage architecture now.
Thus, git allows us to first push our files to staging area, and then we can commit those staged files. Continuing our above example, we can only push those two bug-free complete files to staging area and then further commit our changes. The other two files in progress can remain in our working directory. They can be modified later and committed when you need to. Another important advantage of staging area is that files from staging area can again be pulled to our working directory, if we feel they need some more changes before committing them.
It is to be noted that it is not compulsory in git to first push the files to staging area. The changes can even be directly committed, but it is always a good practice to first stage our files.
I hope the three stage architecture of git is very clear to you now. In my next blog, I will be discussing about adding files to staging area and committing them.
Thanks for reading :)
Feel free to comment your views and queries below, and do give a clap if you feel my article is worth it!