Understand different Git states and the corresponding file states

Let’s learn a bit more about Git basics

Lynn Kwong
3 min readDec 20, 2020


Photo by Mohammad Rahmani on Unsplash.

There are four Git states, namely the local working directory, the staging area, the local repository, and the remote repository.

Different Git states and file states

The local working directory is the folder where the hidden .git folder is located. It is the project folder where you run the git init command or the folder you cloned from GitHub or Git Lab. Only the files inside the project folder can be tracked by git. And any file inside this directory can be tracked, no matter if it is in a subdirectory or not.

The staging area is a virtual git state, files in the staging area have been tracked by git and are ready to be committed to the local repo.

Local repo is a bit more complex and can be confusing for beginners. Local repo is also a virtual git state, normally it refers to the hidden .git folder. This folder handles all the magic heavy lifting work of git. However, the files in the git folder have been treated specially and are not human readable. So don’t bother to find your files there. However, if you make some commits, you will find that the size of the git folder would increase, reflecting that your file changes have been tracked by git.

Remote repo means the remote version of your local repo. However, it is not data in the .git folder but the actual files of your project folder.

Due to the different Git states, there are multiple states for the files in the project folder. If a file has never been added to the git repository, it’s in the untracked state. Once a file is added by git, it’s first in the staging area and thus in the staged state, meaning that it’s ready to be committed to the local repo. When a change is committed, the file is then in the committed state, which means that the staged file has been added to the local repo and can be pushed to the remote repo. If we make changes to a file that has already been tracked, then the changes are first in the modified state in the local working directory, we need to add and commit the changes in order to track them in git.

Finally, the commits in the local repo can be pushed to the remote repo, which will then make our remote repo up to date with the local repo.

Related articles:



Lynn Kwong

I’m a Software Developer (https://superdataminer.com) keen on sharing thoughts, tutorials, and solutions for the best practice of software development.