We can get a less verbose version of the status of our project by running
git status -s
To show how this works, suppose that we've created a new file file2.txt and modified an existing file, file1.txt. In the short version of the status each file name is preceded by two columns: the left column represents the staging area, and the right column represents the working directory.
In this example, file1.txt is shown with a red M. Git is telling us that this file has been modified, but that this modification is not in the staging area, only in the working directory. file1.txt has nothing in the left column since there are no changes in this file affecting its staging area status.
If we stage file1.txt and run git status -s again, we see that now file1.txt has a green M on the left column. This means that all the changes we had in the working area are now in the staging area. The right column is now empty because we don't have any other changes to add.
Now let's make some more changes to file1.txt and run git status -s one more time. Git is now showing a green M on the left-hand column and a red M on the right-hand column. This means that there are staged changes and un-staged changes. To add the new changes to the staging area we just run
git add file1.txt
Now let's take a look at file2.txt. This file has two red ?? because it's a new file. To add it to the staging area we just run git add file2.txt. Now the Git status has a green A on the left-hand side column. This means that the file is new, and it's in the staging area. We can go ahead and commit it if we are satisfied with the changes by running
git commit -m "Add file2.txt"
If we now delete both files, Git will show them with a green D on the left-hand column. This means that they are both going to be deleted.
If at any time you run git status -s and there are no changes to neither the working nor the staging area, Git will show an empty line.
