Git has three main states that your files can reside in:
These three states make a system based on promotion. Each file can reside in one of these three states and change states depending on what was done to it.
This state indicates that the file is safely stored in the local database.
When any change to the file occurs, the state of the file changes from committed to modified. This means that the document has changed since its last committed version which is saved to our local database. We can see this state as 'we're currently working on this file, there will still be more changes'.
When we're finished with all the modifications to our file, it moves to the staged state. The file is now ready to be added to the local git database, you have marked it to go into your next commit snapshot.
It's important to note that these three file states refer only to files tracked in a Git project. A file can be in a project but the changes to it are not tracked by Git. When we start tracking changes in Git for a file we haven't been tracking, it automatically goes into the staged state.
Three Sections of a Git Project
Similar to how files can be in three different states, a Git project consists of three different sections.
The first section is the .git directory, also known as the repository. This is where Git stores the metadata and object database for your project.
The next section is the working directory. This is a single checkout of one version of the project. This is where you can modify files.
The third section is the staging area, also known as the index. It's the area between the working directory and the .git directory. All the files which are ready for a commit are stored here.
When we commit, what is in the staging area moves to the new version of the repository. This excludes what is in the working directory. This allows us to change files however we like, but only what we move to the staging area will be committed. Everything we changed but do not want to put in a repository stays in the working directory.