A copy is on the local system ready to edit. As soon as any changes are made Git recognizes the file as modified and moves it to the modified status. Running git status will show this:
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: filename
#
The file has been changed but as of yet it will not be committed (after all, more changes can still be made and it may not be ready to be committed). As the output helpfully points out, using the git add filename command again will push the modified file to the staged status, ready to be committed.
$ git add filename
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: filename
#
This process can become a little more complex if a staged file needs to have one final edit before it is committed as it will appear in both the staged status and the modified status. If this occurs then a status will look like this:
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: filename1
#
# Changed but not updated:
# (use "git add <file>..." to unstage)
#
# modified: filename1
#
This is where the Git snapshots are highlighted; there is a snapshot of a file ready to be committed and another snapshot in the modified status. If a commit is run then only the snapshot of the staged status will be committed, not the corrected version. Running git add again will resolve this and the modified snapshot of the file will merge with the snapshot on the staged status, ready to commit the new changes.
