Checking Status and Differences: Mastering Git Visibility

Previously in this course, we covered the fundamentals of tracking files and creating your first commit. Now that you know how to save your work, you need to know how to "look under the hood" to see exactly what is happening in your project before you finalize those changes.

In professional environments, we rarely commit "blindly." We use two essential tools to maintain transparency: git status for the big picture and git diff for the granular details.

Checking Status with git status

The git status command is your primary dashboard. It tells you which files are tracked, which are modified, and which are currently in the staging area waiting to be committed.

Think of it as a sanity check. Whenever you return to your terminal, running git status is the best way to orient yourself.

How to use it

Navigate to your project directory and run:

Bash
git status

Git will categorize your files into three main buckets:

1. Untracked files: New files you haven't told Git to track yet.
2. Changes to be committed: Files you've added to the staging area (using git add).
3. Changes not staged for commit: Files you’ve edited, but haven't added to the staging area yet.

Viewing Changes with git diff

While git status tells you which files changed, git diff shows you the actual content of those changes. It performs a line-by-line comparison between your working directory and the last commit.

Anatomy of a Diff

When you run git diff, you will see output that looks like this:

DIFF
--- a/README.md
+++ b/README.md
@@ -1,4 +1,5 @@
 # Project Title
 
-Old version
+New version

• - (Red): Lines removed.
• + (Green): Lines added.
• @@ ... @@: The "hunk header," indicating where in the file the changes are occurring.

Hands-on Exercise: Tracking and Verifying

Let's apply this to our running project. Follow these steps to see the lifecycle in action:

1. Modify a file: Open your README.md and add a line of text.
2. Check status: Run git status. You will see the file listed under "Changes not staged for commit."
3. Inspect the changes: Run git diff. Notice the green + line showing your addition.
4. Stage the change: Run git add README.md.
5. Check status again: Run git status. Notice the file has moved to "Changes to be committed."
6. Verify the staged diff: Run git diff --staged. This is a pro-tip: git diff alone only shows unstaged changes. Adding the --staged flag lets you review exactly what will be included in your next commit.

Common Pitfalls

• Forgetting to save: Git looks at the file on your disk. If you edited a file in your text editor but didn't hit "Save," git status won't show anything. Always save your files before checking your status.
• Confusing git diff vs git diff --staged: Many beginners run git diff after staging a file and panic because they see no output. Remember that git diff compares your working directory to the index (staging area), whereas --staged compares the index to your last commit.
• Ignoring the output: It’s easy to skim the status output. Always verify that you aren't accidentally staging temporary files or IDE-specific configuration files that shouldn't be in version control.

FAQ

Why does my terminal show colors? Git usually detects your terminal's capabilities automatically. Colors help you distinguish between additions (green) and deletions (red) instantly.

Can I see changes for one specific file? Yes. Use git diff <filename> to isolate the comparison to just that file. This is useful when you have many changes across multiple files.

Does git diff change my files? No. git diff is a read-only command. It is strictly for inspection and will never alter your code.

Recap

You now have the visibility required to work with confidence. Use git status to maintain a high-level view of your project state and git diff to perform precise code reviews of your own work before committing. If you ever feel lost in your project, these two commands are the best way to find your way back.

Up next, we will learn how to clean up your workspace by using .gitignore to prevent unwanted files from cluttering your repository.