Git State of Mystery

Explaination of the three states

As teams get bigger and projects more complex there arises a need for tools which can keep track of all the changes made to the project by each team member, allow each member to work on their copies of the project simultaneously without breaking the project for each other, help collaborate and combine the changes made by different members, rollback certain changes and a whole lot more, all for the sake of efficient workflow of the project and effective collaboration between team members. To achieve all this and much more, there comes into the picture this seemingly magical but in reality, a well designed and intelligent tool know as Git. Git as it says on its official website " is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency".
To try and understand how to use Git to our advantage and equally or perhaps more importantly understand how Git works behind the curtains to makes all this sorcery possible we will have to understand the 3 different states in which our files can exist while working with Git, which are modified state, staged state and committed state. But before we start with the fun part of demystifying the mystic Git file states we will have to eat some of our vegetables, that is, we need to understand some basics about Git. On a high-level Git works by collecting complete snapshots of the project at different times in an orderly fashion and then helping us manage these snapshots. These snapshots contain all the files in all the branches of the project at that particular time and Git can help users add new snapshots, merge different snapshots, revert to an older snapshot and execute a whole range of other important procedures with these snapshots.
Now finally to the part for which we came here, let’s start exploring and understanding the 3 states in which a file can exist in while using Git.

Modified State

Modified state probably has the most descriptive name of a state among the 3 we are going to discuss and so as the name suggests a file is in the modified state, well, when it is modified as simple as that. As we now know Git works by managing snapshots of our projects and these snapshots, in a way, contain all the files and their contents at the time of the snapshot. Therefore, it is desirable to know if there has been any change in the project since the last snapshot, may it be the addition or deletion of a single character in a file inside the project repository or the addition or deletion of complete files themselves. Each and every file being tracked by Git, whenever goes through any small or large change the file gets into the modified state.
To check the state of all the files in the repository we can use the command git status and to check the state of a sub-directory or a file the command can be used with the desired path as an argument git status [path/to/file]. Another useful command is the git diff command which outputs the modifications that have taken place in the repository since the last snapshot or git diff [path/to/file] which outputs the modifications in the specified file.
To understand this through a metaphor, think of yourself as a photographer. So, you have clicked a photograph and now would like to click another one, you look through the lens and set a frame. Now, if everything in the frame is exactly the same as the last photograph you clicked then it is somewhat safe to say that there is no need of clicking a new photograph, but as soon as there occurs any change at all in the frame then now you can say that you are looking at a modified state.

Staged State

Staged state of a file is when you have decided that you would like the file, which previously was in modified state to be present with all its changes in the next snapshot. It could be thought of as a pre-final state before finally, the file goes into the committed state(more on this later). The file that enters the staged state is said to be added to the staging area and now is ready to be in the next snapshot, any changes done to the file after it has been staged will not be present in the next snapshot unless and until it is once again staged with all these new changes.
Once again, the command git status can be used to find out the state of the file/files. The command used to add files into the staging area, that is, to change their state to staged state is git add [path/to/file] and a neat way to add all the modified files in the repository to staging area is by using the git add . command.
To continue with our metaphor, the staging state is similar to clicking a photograph. The content of the frame at that time and in that condition would be saved in the memory of the camera, any more changes in the frame would not be captured in the photograph as it has already been clicked and so the only way to capture these changes are by again clicking a photograph with the changed frame.

Committed State

Committed stage is the final state that the file would be in locally at your system. It is the committed state of a file that ends up in a snapshot. All files which were previously in the staged state, that is, files added to the staging area, after the command to commit change their state from staged state to committed state. Git packages all the content of the staging area into a single commit which can be used to refer to the snapshot of the repository at that moment of time. Each commit also points to its predecessor commit and thus when these commits are pushed to the remote repository then they should not be deleted or tampered with as other collaborators’ commits may link to these commits. Thus files in committed state represent files that will be present in the snapshot of the repository.
The command used to change the state of all the files in the staging area from staged state to committed state and thus package all of them into a commit is git commit -m "message", here the option -m with the message as a string argument is used to attach a meaningful message along with the commit which would help you and other collaborators to understand why the commit was made.
Now, going back to our metaphor once again, the committed state of a file is analogous to getting the photograph we had in the memory of the camera and printing it out. Now, this photograph is immutable and represents everything present in the frame at the moment of time when the photograph was clicked. Therefore, pushing the commit onto remote repository could be thought of as pasting this photograph in a shared scrapbook for all who have the access to the scrapbook to see. Other collaborators may add their photographs in the scrapbook and thus, removing a photograph from the scrapbook would leave a blank space and thus destroy the integrity of the scrapbook.