How to Check If a File Is Staged in Git

GitGitBeginner
Practice Now

Introduction

In this lab, you will learn how to check if a file has been staged in Git. We will explore the git status command to see the state of your repository and identify staged files. You will then use git diff --cached to verify the specific changes that are currently in the staging area, providing a clear view of what will be included in your next commit. Finally, you will test with unstaged files to further solidify your understanding of the staging process.


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL git(("Git")) -.-> git/BasicOperationsGroup(["Basic Operations"]) git/BasicOperationsGroup -.-> git/add("Stage Files") git/BasicOperationsGroup -.-> git/status("Check Status") git/BasicOperationsGroup -.-> git/diff("Compare Changes") subgraph Lab Skills git/add -.-> lab-560031{{"How to Check If a File Is Staged in Git"}} git/status -.-> lab-560031{{"How to Check If a File Is Staged in Git"}} git/diff -.-> lab-560031{{"How to Check If a File Is Staged in Git"}} end

Check git status for Staged Files

In this step, we will check the status of our Git repository after adding a file to the staging area. This will help us understand how Git tracks changes before they are committed.

First, make sure you are in your my-time-machine directory. You can use the cd command to navigate there:

cd ~/project/my-time-machine

Now, let's create a new file called future_plans.txt and add some content to it:

echo "Plan 1: Build a bigger time machine" > future_plans.txt

This command creates the file and writes the text "Plan 1: Build a bigger time machine" into it.

Next, we will add this new file to the staging area using the git add command:

git add future_plans.txt

Remember, git add stages the changes, preparing them for the next commit. It doesn't create the commit itself yet.

Now, let's check the status of our repository using git status:

git status

You should see output similar to this:

On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   future_plans.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        message.txt ## This file is already committed, but Git status shows it differently after a commit. Don't worry about this for now.

Notice the "Changes to be committed:" section. This indicates that future_plans.txt is now in the staging area, ready to be included in the next commit. Git recognizes it as a "new file".

Understanding the staging area is crucial in Git. It allows you to group related changes together before making a commit. This means you can work on multiple things, but only commit specific changes when they are ready.

Use git diff --cached to Verify

In this step, we will learn how to see the changes that are currently in the staging area. This is where the git diff command comes in handy, specifically with the --cached option.

Make sure you are still in the ~/project/my-time-machine directory.

We previously added future_plans.txt to the staging area. Now, let's use git diff --cached to see exactly what changes are staged:

git diff --cached

You should see output similar to this:

diff --git a/future_plans.txt b/future_plans.txt
new file mode 100644
index 0000000..a1b2c3d
--- /dev/null
+++ b/future_plans.txt
@@ -0,0 +1 @@
+Plan 1: Build a bigger time machine

Let's break down this output:

  • diff --git a/future_plans.txt b/future_plans.txt: This line indicates that Git is showing the difference between two versions of the file future_plans.txt.
  • new file mode 100644: This shows that future_plans.txt is a new file.
  • index 0000000..a1b2c3d: These are internal Git identifiers for the file's content.
  • --- /dev/null and +++ b/future_plans.txt: These lines indicate that the file is being compared from nothing (/dev/null) to the new version of future_plans.txt.
  • @@ -0,0 +1 @@: This is a "hunk header" indicating the lines that have changed. -0,0 means zero lines from the original (non-existent) file, and +1 means one line in the new file.
  • +Plan 1: Build a bigger time machine: The + sign at the beginning of the line indicates that this line has been added.

The git diff --cached command shows you the difference between the staging area and the last commit. Since we haven't made any commits yet in this repository (except the initial one in the previous lab), it shows the difference between the staging area and an empty state.

This command is incredibly useful for reviewing your staged changes before you commit them. It helps you ensure that you are only committing the changes you intend to.

Press q to exit the diff view and return to the command line.

Test Unstaged Files

In this step, we will explore how Git handles changes that have been made to a tracked file but have not yet been added to the staging area. These are called "unstaged" changes.

Make sure you are in the ~/project/my-time-machine directory.

We previously created and staged future_plans.txt. Now, let's add another line to this file without staging the change:

echo "Plan 2: Invent a self-folding laundry machine" >> future_plans.txt

The >> operator appends the text to the existing file, rather than overwriting it.

Now, let's check the status of our repository again:

git status

You should see output similar to this:

On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   future_plans.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:   future_plans.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        message.txt

Notice the new section: "Changes not staged for commit:". This tells us that Git sees changes in future_plans.txt that are different from the version in the staging area. The file is listed as "modified".

This is a key concept in Git: the working directory (where you make changes) is separate from the staging area. You can have changes in your working directory that are not yet staged.

To see the difference between the working directory and the staging area, you can use git diff without any options:

git diff

You should see output similar to this:

diff --git a/future_plans.txt b/future_plans.txt
index a1b2c3d..e4f5g6h 100644
--- a/future_plans.txt
+++ b/future_plans.txt
@@ -1 +1,2 @@
 Plan 1: Build a bigger time machine
+Plan 2: Invent a self-folding laundry machine

This output shows the difference between the version of future_plans.txt in the staging area (which only has "Plan 1") and the version in your working directory (which now has both "Plan 1" and "Plan 2"). The + sign again indicates the added line.

Understanding the difference between staged and unstaged changes, and how to view them with git status and git diff, is fundamental to using Git effectively.

Press q to exit the diff view.

Summary

In this lab, we learned how to check if a file is staged in Git. We started by creating a new file and adding it to the staging area using git add. We then used git status to observe that the file was listed under "Changes to be committed," confirming it was staged.

We also explored using git diff --cached to view the specific changes that are currently in the staging area, providing a detailed look at what will be included in the next commit. Finally, we tested the behavior of git status with unstaged files to differentiate between staged and unstaged changes.