Tracking Content through the File Status Life Cycle

In this lab, you’ll work through some simple examples of updating files in a local environment and viewing the files’ status and differences between the various levels along the way.

Prerequisites

This lab assumes that you have done Connected Lab 2: Creating and Exploring a Git Repository and Managing Content. You should start out in the same directory as that lab.

Steps

1. Starting in the same directory as you used for Connected Lab 2, run the status command or the short form to see how it looks when you have no changes to be staged or committed.

   $ git status
   $ git status –s

2. Create a new file and view the status.

   $ echo content > file3.c
   $ git status
   $ git status –s

   Question:

   1. Is the file tracked or untracked?

   Answer:

   1. It’s untracked—you haven’t added the initial version to Git yet.
3. Stage the file and check its status.

   $ git add .   (or git add file3.c)
   $ git status   (git status –s if you want)

   Questions:

   1. Is the file tracked or untracked?
   2. What does Changes to be committed mean?

   Answers:

   1. The file is now tracked—you’ve added the initial version to Git.
   2. Changes to be committed implies that files exist in the staging area and the next step for them is to be committed into the local repository.
4. Edit the same file again in your working directory and check the status.

   $ echo change > file3.c
   $ git status

   Questions:

   1. Why do you see the file listed twice?
   2. Where is the version that’s listed as Changes to be committed (in the working directory, staging area, or local repository)?
   3. Where is the version that’s listed as Changes not staged for commit (in the working directory, staging area, or local repository)?

   Answers:

   1. You see the file listed twice because there is one version of the same file in the working directory and another version in the staging area.
   2. The version that’s listed as Changes to be committed is in the staging area. The phrase implies that this version’s next step or next level for promotion is to the local repository using a commit.
   3. The version that’s listed as Changes not staged for commit is in the working directory. The phrase implies that this version’s next step or next level for promotion is to the staging area, because it’s currently not staged.
5. Do a diff between the version in the working directory and the version in the staging area.

   $ git diff

6. Go ahead and commit and do another status check.

   $ git commit –m "comment"
   $ git status

   Question:

   1. Which version did you commit: the one in the staging area or the one in the working directory? (Hint: Which one is left [shows up in the status]? Note the Changes not staged for commit part of the status message.)

   Answer:

   1. The version in the staging area was the one committed. The content goes through the staging area and then into the local repository.
7. Stage the modified file you have in your working directory and do a status check.

   $ git add .$ git status

8. Edit the file in the working directory one more time and do a status check.

   $ echo "change 2" > file3.c$ git status

   At this point, you have a version of the same file in the local repository (the one you committed in step 6), a version in the staging area (the one you staged in step 7), and a version in the working directory (step 8).

9. Diff the version in the working area against the version in the staging area.

   $ git diff

10. Diff the version in the staging area against the version in the local repository.

    $git diff --staged (or git diff --cached) (note that the “--” is a double hyphen)

11. Diff the version in the working directory against the version in the local repository (the one you committed earlier).

    $ git diff HEAD

12. Commit using the shortcut.

    $ git commit –am "committing another change"

    Question:

    1. Which version was committed (the one in the working directory or the one in the staging area)?

    Answer:

    1. Because you used the -am shortcut, the version from the working directory was staged (over the previous version in the staging area) and then that version was committed into the local repository.
13. Check the status one more time.

    $ git status

    Notice the output. You’re back to a clean working directory—Git has the latest versions of everything you’ve updated.