git tips and tricks — Staging and unstaging changes in git workflow

This is another post in serie on git tips and tricks. In this post I will show how staging and unstaging works in git under the hood.

Working with git workflow can be quite tricky for beginners. Here I will show how staging and unstaging of local changes works on hands on practical example.

Let’s create some test repository on github and clone it. I guess It’s simple enough so skipping this part and moving on to work with local copy of repo.

Assume we have cloned a repo. Now let’s add some file foo.txt.

touch foo.txt

and add some text

echo "Update 1" > foo.txt

Check the content of file

$ cat foo.txt
Update 1

Check status of repo

$ git status
Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
   (use "git restore <file>..." to discard changes in working directory)
         modified:   foo.txt

We can see that file foo.txt was modified but changes “are not staged for commit”. First we need to stage them.

To stage changes we need to use command “git add”

$ git add foo.txt

Check status of changes in repo:

$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
   (use "git restore --staged <file>..." to unstage)
         modified:   foo.txt

Now changes are staged and ready to be committed.

Let’s make another change and see what happen

$ echo "Update 2" > foo.txt
$ cat foo.txt
Update 2

Check status of changes in repo

$ git status
...
Changes to be committed:
   (use "git restore --staged <file>..." to unstage)
modified:   foo.txt
Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
   (use "git restore <file>..." to discard changes in working directory)
         modified:   foo.txt

We see that we have staged changes (line “Update 1” we already staged) and new unstaged changes (line “Update 2” newly added). This mean that git tracking both changes for us.

We can restore last change to file foo.txt

git restore .

Check content of file and status of repo:

$ cat foo.txt
Update 1
$ git status
...
Changes to be committed:
   (use "git restore --staged <file>..." to unstage)
         modified:   foo.txt

We see that file foo.txt contains now the string “Update 1” from staged version.

Let’s add new change and stage the change

$ echo "Update 2" > foo.txt
$ cat foo.txt
Update 2
$ git add foo.txt
$ git status
...
Changes to be committed:
   (use "git restore --staged <file>..." to unstage)
         modified:   foo.txt

Now try one more update. Change line “Update 2” to “Update 3”

$ echo "Update 3" > foo.txt
$ cat foo.txt
Update 3
$ git status
...
Changes to be committed:
   (use "git restore --staged <file>..." to unstage)
         modified:   foo.txt
Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
   (use "git restore <file>..." to discard changes in working directory)
         modified:   foo.txt

Just notice that new change (“Update 3”) is now unstaged. If we restore change we return to string “Update 2” in file foo.txt

$ git restore .
(master) $ cat foo.txt
Update 2

We can’t restore changes to the point we had string “Update 1” in foo.txt. This chnages was already rewritten by staged change with string “Update 2”. If we you want to revert all uncommitted changes use command reset with flag — hard:

git reset --hard

That’s it.