The Staging Area

The staging area is one of Git's most distinctive features, giving you precise control over what goes into each commit. While you've already used it with git add, understanding how it works at a deeper level will make you a more effective Git user. In this lesson, you'll master the three-tree architecture, learn advanced staging techniques, and discover how to craft perfect commits by staging exactly what you want—no more, no less.

Git's Three-Tree Architecture

Git manages your project using three main "trees" (areas that hold different versions of your files):

The Three Trees

Working Directory: Your actual project files where you work
Staging Area (Index): A preparation area for your next commit
Repository (HEAD): The committed history stored in .git

How They Work Together

Think of it as a photography workflow:

TEXT

Working Directory  →  Staging Area  →  Repository
   (edit files)     (git add)      (git commit)
   
   Your desk      →  Photo setup  →  Photo album
   (messy work)      (staged shot)    (final photo)

Working Directory: Where you actually edit files. This is your project folder with all your files visible and editable.
Staging Area: A holding area where you organize changes before permanently saving them. You choose exactly which changes to include.
Repository: The permanent record of your project's history. Once committed, changes are safely stored here.

📸 The Photography Analogy

Imagine you're taking a group photo:

Working Directory: Everyone standing around casually (files being edited)
Staging Area: You arrange people for the photo, adjust lighting, set the scene (choosing what to commit)
Repository: You take the photo and it's permanently saved (committed)

You can rearrange people (unstage changes) before taking the photo, but once you press the button (commit), that moment is captured forever!

Why Does the Staging Area Exist?

Most version control systems go directly from "edited" to "committed". Git's staging area adds an extra step. Why?

Reason 1: Selective Commits

You can commit only some of your changes:

TEXT

You modified 5 files:
- bug-fix.js (fixed a bug) ✓ Stage this
- feature.js (new feature) ✓ Stage this
- debug.js (temporary debug code) ✗ Don't stage
- test.js (experimental test) ✗ Don't stage
- notes.txt (personal notes) ✗ Don't stage

Commit message: "Fix login bug and add password validation"
(Only the first 2 files are committed)

Reason 2: Logical Grouping

You can group related changes into separate commits even if you made them all at once:

BASH

# You fixed 3 bugs in 3 different files
# Instead of one messy commit, make 3 focused commits:

git add bug1.js
git commit -m "Fix login redirect issue"

git add bug2.js
git commit -m "Fix header overflow on mobile"

git add bug3.js
git commit -m "Fix email validation regex"

Reason 3: Review Before Committing

The staging area lets you review exactly what you're about to commit:

BASH

# Stage some changes
git add index.html styles.css

# Review what you're about to commit
git diff --staged

# Looks good? Commit it!
git commit -m "Update homepage layout"

Reason 4: Incremental Staging

You can stage parts of a file, not just entire files (we'll learn this soon):

BASH

# Stage only some changes from a file
git add -p large-file.js

# Git asks about each change:
# "Stage this hunk? [y,n,q,a,d,/,e,?]"

Understanding File States

Files in your Git repository can be in several states:

Untracked

Files that Git isn't watching yet. Brand new files you just created.

BASH

# Create a new file
echo "New file" > newfile.txt

# Git sees it but isn't tracking it yet
git status
# Untracked files:
#   newfile.txt

Unmodified

Files that Git is tracking but haven't been changed since the last commit.

Modified

Files that have been changed but not yet staged.

BASH

# Edit an existing file
echo "More content" >> index.html

# Git sees it's changed
git status
# Changes not staged for commit:
#   modified:   index.html

Staged

Files that have been marked to go into the next commit.

BASH

# Stage the change
git add index.html

# Now it's staged
git status
# Changes to be committed:
#   modified:   index.html

The Lifecycle

Files move through these states:

TEXT

Untracked → [git add] → Staged → [git commit] → Unmodified
                                                        ↓
                                                    [edit file]
                                                        ↓
                                                    Modified → [git add] → Staged

Git Status: A Deep Dive

git status is your window into the three trees. Let's learn to read it like a pro.

Understanding the Output

BASH

git status

TEXT

On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   contact.html
        modified:   index.html

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:   styles.css
        deleted:    old-page.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        script.js
        images/logo.png

Let's break this down:

Changes to be committed (Staged):

These changes are in the staging area and will be included in your next commit:

contact.html - New file, staged
index.html - Modified file, staged

Changes not staged for commit (Modified):

These files are tracked by Git and have been modified, but the changes aren't staged:

styles.css - Changed but not staged
old-page.html - Deleted but deletion not staged

Untracked files:

These files exist in your working directory but Git isn't tracking them:

script.js - New file, not yet added to Git
images/logo.png - New file in subdirectory

Short Status

For a more compact view:

BASH

git status -s
# or
git status --short

TEXT

A  contact.html
M  index.html
 M styles.css
 D old-page.html
?? script.js
?? images/

The status codes:

?? - Untracked files
A - Added (new file, staged)
M - Modified and staged (left column)
M - Modified but not staged (right column)
MM - Modified, staged, then modified again
D - Deleted but not staged
D - Deleted and staged

Advanced Staging Techniques

Stage Specific Files

BASH

# Stage one file
git add index.html

# Stage multiple specific files
git add index.html styles.css script.js

# Stage all files in a directory
git add src/

# Stage all JavaScript files
git add *.js

Stage All Changes

BASH

# Stage everything in current directory and subdirectories
git add .

# Stage all changes in entire repository (from any directory)
git add -A
# or
git add --all

# Stage modified and deleted files (not new files)
git add -u
# or
git add --update

Interactive Staging

Stage parts of files selectively (patch mode):

BASH

git add -p filename
# or
git add --patch filename

Git will show each change and ask what to do:

TEXT

Stage this hunk [y,n,q,a,d,/,s,e,?]?

y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any remaining hunks
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any later hunks in the file
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help

✂️ Patch Mode Power

Patch mode is incredibly powerful! You can commit different parts of the same file in separate commits. This is perfect when you made multiple unrelated changes to one file.

Stage and Commit in One Command

BASH

# Stage all tracked files and commit
git commit -a -m "Update multiple files"
# or
git commit -am "Update multiple files"

# WARNING: This only stages TRACKED files
# It won't stage new (untracked) files!

Unstaging Changes

Sometimes you stage something by accident. Here's how to unstage:

Modern Way (Git 2.23+)

BASH

# Unstage a specific file
git restore --staged filename.txt

# Unstage all files
git restore --staged .

Traditional Way

BASH

# Unstage a specific file
git reset HEAD filename.txt

# Unstage all files
git reset HEAD

Important: Unstaging doesn't discard your changes! It just moves them from the staging area back to the working directory. Your modifications are still there.

The Difference Between Unstaging and Discarding

BASH

# UNSTAGE: Remove from staging area, keep changes
git restore --staged file.txt
# Changes still in working directory

# DISCARD: Throw away changes completely (DANGEROUS!)
git restore file.txt
# Changes are gone forever!

Warning: git restore file.txt (without --staged) permanently deletes your uncommitted changes! Make sure you really want to discard them.

Viewing Changes

See Unstaged Changes

BASH

# Show changes not yet staged
git diff

# Show changes for a specific file
git diff filename.txt

This compares your working directory with the staging area. It shows what you changed but haven't staged yet.

See Staged Changes

BASH

# Show changes that are staged
git diff --staged
# or
git diff --cached

# Show staged changes for a specific file
git diff --staged filename.txt

This compares the staging area with the last commit. It shows exactly what will be in your next commit.

See All Changes

BASH

# Show all changes (staged and unstaged)
git diff HEAD

# This compares working directory with last commit

Comparison Table

TEXT

Command              | Compares
---------------------|----------------------------------
git diff             | Working Dir ↔ Staging Area
git diff --staged    | Staging Area ↔ Last Commit (HEAD)
git diff HEAD        | Working Dir ↔ Last Commit (HEAD)

🔍 Always Review Before Committing

Make it a habit to run git diff --staged before git commit. This shows you exactly what you're about to commit and helps catch mistakes!

Practical Scenarios

Scenario 1: Selective Staging

You worked on three different things and want to commit them separately:

BASH

# You modified:
# - auth.js (login bug fix)
# - dashboard.js (new feature)
# - utils.js (refactoring)

# Commit 1: Bug fix
git add auth.js
git commit -m "Fix login redirect bug"

# Commit 2: New feature
git add dashboard.js
git commit -m "Add user dashboard with analytics"

# Commit 3: Refactoring
git add utils.js
git commit -m "Refactor date formatting utilities"

# Result: 3 clear, focused commits instead of 1 messy one

Scenario 2: Staging Part of a File

You made two unrelated changes to the same file:

BASH

# app.js has:
# - Bug fix in lines 10-15
# - New feature in lines 50-70

# Stage only the bug fix
git add -p app.js

# When Git shows the bug fix section:
# y (yes, stage this)

# When Git shows the feature section:
# n (no, don't stage this)

# Commit just the bug fix
git commit -m "Fix null pointer exception in login"

# Later, stage and commit the feature
git add app.js
git commit -m "Add password strength indicator"

Scenario 3: Reviewing Before Committing

BASH

# Make some changes
git add .

# Wait, what did I just stage?
git diff --staged

# Oh no, I staged debug code by accident!
git restore --staged debug.js

# Now check again
git status

# Looks good, commit
git commit -m "Update homepage layout"

Scenario 4: Mixed State

Same file can be both staged and modified:

BASH

# Edit index.html
echo "Line 1" >> index.html

# Stage it
git add index.html

# Edit it again
echo "Line 2" >> index.html

# Now check status
git status
# Changes to be committed:
#   modified:   index.html
#
# Changes not staged for commit:
#   modified:   index.html

# The first change is staged, the second isn't!

# To commit both:
git add index.html
git commit -m "Update index.html"

# Or to commit only the first change:
git commit -m "Add Line 1 to index.html"
# (Line 2 remains uncommitted)

Staging Deletions and Renames

Deleting Files

BASH

# Wrong way: Just deleting the file
rm oldfile.txt
git add oldfile.txt  # This stages the deletion

# Right way: Using git rm
git rm oldfile.txt   # Deletes AND stages in one command

# To delete from Git but keep in working directory
git rm --cached oldfile.txt

Moving/Renaming Files

BASH

# Wrong way: Manual move
mv old.txt new.txt
git add old.txt new.txt

# Right way: Using git mv
git mv old.txt new.txt  # Moves AND stages in one command

Git is smart about moves: Even if you manually move a file, Git can usually detect that it was renamed (not deleted and recreated) as long as the content is similar enough.

Practice Staging Commands

Try these commands to practice working with the staging area:

Practice Staging Operations

Experiment with staging and viewing changes

Try these examples:

Staging Best Practices

1. Check Status Frequently

Run git status often to understand what state your files are in.

2. Review Before Staging

BASH

# See what changed
git diff

# Looks good? Stage it
git add file.txt

3. Review Before Committing

BASH

# What am I about to commit?
git diff --staged

# Perfect? Commit it
git commit -m "Message"

4. Stage Logically Related Changes

Each commit should be a logical unit. Use selective staging to group related changes together.

5. Don't Stage Everything Blindly

Be careful with:

BASH

git add .

This stages everything. Make sure you actually want to commit all changes! Always run git status first.

6. Use .gitignore

Don't stage files that shouldn't be in version control:

.gitignore

node_modules/
.env
.DS_Store
*.log
dist/

7. Commit Often, Perfect Later

It's okay to make frequent small commits. You can always clean up your history later (advanced topic).

Common Staging Mistakes

Mistake 1: Committing Sensitive Data

Problem: Accidentally staged passwords or API keys

Prevention:

BASH

# Add sensitive files to .gitignore FIRST
echo ".env" >> .gitignore
echo "secrets.json" >> .gitignore

# Then stage everything else
git add .

Mistake 2: Staging Debug Code

Problem: Staged files with console.log() or debug statements

Solution:

BASH

# Review what you're staging
git diff --staged

# Oops, debug code!
git restore --staged debug-file.js
# Remove the debug statements
# Stage again
git add debug-file.js

Mistake 3: Forgot to Stage New Files

Problem: Committed but new files weren't included

Solution:

BASH

# Always check status before committing
git status

# See untracked files? Add them!
git add new-file.js

# Or use commit --amend to add to last commit
git add new-file.js
git commit --amend --no-edit

Command Reference

Here's a quick reference of all staging commands:

BASH

# Staging Files
git add filename              # Stage specific file
git add .                     # Stage all in current directory
git add -A                    # Stage all changes everywhere
git add -u                    # Stage modified/deleted (not new)
git add *.js                  # Stage all JavaScript files
git add -p filename           # Interactive staging (patch mode)

# Unstaging Files
git restore --staged filename # Unstage specific file
git restore --staged .        # Unstage everything
git reset HEAD filename       # Unstage (traditional way)

# Viewing Changes
git status                    # See file states
git status -s                 # Short status
git diff                      # Unstaged changes
git diff --staged             # Staged changes
git diff HEAD                 # All changes

# Discarding Changes (DANGEROUS!)
git restore filename          # Discard unstaged changes
git restore .                 # Discard all unstaged changes

# Deleting and Moving
git rm filename               # Delete and stage
git rm --cached filename      # Remove from Git, keep file
git mv oldname newname        # Move/rename and stage

Key Takeaways

Git uses three trees: Working Directory, Staging Area, and Repository
The staging area gives you precise control over what goes into each commit
Files can be untracked, unmodified, modified, or staged
git status shows you the state of all three trees
git add moves changes to the staging area
git restore --staged unstages changes without discarding them
git diff shows unstaged changes
git diff --staged shows what will be in the next commit
You can stage part of a file with git add -p
Always review changes before staging and before committing

What's Next?

Excellent work! You now have a deep understanding of Git's staging area and the three-tree architecture. You can selectively stage changes, review what you're about to commit, and craft perfect commits that contain exactly what you intend.

In the next lesson, we'll explore undoing changesin Git. You'll learn how to safely undo mistakes, recover from errors, and rewrite history when needed. We'll cover git restore, git reset, git revert, and understand when to use each one. Making mistakes is normal—knowing how to fix them is what makes you a confident Git user!

🎯 Practice Assignment

Before the next lesson, practice working with the staging area:

Create multiple files and make changes to existing ones
Practice staging files selectively (not with git add .)
Use git diff and git diff --staged to review changes
Practice unstaging files with git restore --staged
Try patch mode (git add -p) on a file with multiple changes
Create commits with only related changes grouped together

Test Your Understanding of the Staging Area

Question 1 of 4

What is the staging area in Git?

Current Score0 / 0

Git's Three-Tree Architecture

Git manages your project using three main "trees" (areas that hold different versions of your files):

The Three Trees

Working Directory: Your actual project files where you work
Staging Area (Index): A preparation area for your next commit
Repository (HEAD): The committed history stored in .git

How They Work Together

Think of it as a photography workflow:

TEXT

Working Directory  →  Staging Area  →  Repository
   (edit files)     (git add)      (git commit)
   
   Your desk      →  Photo setup  →  Photo album
   (messy work)      (staged shot)    (final photo)

Working Directory: Where you actually edit files. This is your project folder with all your files visible and editable.
Staging Area: A holding area where you organize changes before permanently saving them. You choose exactly which changes to include.
Repository: The permanent record of your project's history. Once committed, changes are safely stored here.

📸 The Photography Analogy

Imagine you're taking a group photo:

Working Directory: Everyone standing around casually (files being edited)
Staging Area: You arrange people for the photo, adjust lighting, set the scene (choosing what to commit)
Repository: You take the photo and it's permanently saved (committed)

You can rearrange people (unstage changes) before taking the photo, but once you press the button (commit), that moment is captured forever!

Why Does the Staging Area Exist?

Most version control systems go directly from "edited" to "committed". Git's staging area adds an extra step. Why?

Reason 1: Selective Commits

You can commit only some of your changes:

TEXT

You modified 5 files:
- bug-fix.js (fixed a bug) ✓ Stage this
- feature.js (new feature) ✓ Stage this
- debug.js (temporary debug code) ✗ Don't stage
- test.js (experimental test) ✗ Don't stage
- notes.txt (personal notes) ✗ Don't stage

Commit message: "Fix login bug and add password validation"
(Only the first 2 files are committed)

Reason 2: Logical Grouping

You can group related changes into separate commits even if you made them all at once:

BASH

# You fixed 3 bugs in 3 different files
# Instead of one messy commit, make 3 focused commits:

git add bug1.js
git commit -m "Fix login redirect issue"

git add bug2.js
git commit -m "Fix header overflow on mobile"

git add bug3.js
git commit -m "Fix email validation regex"

Reason 3: Review Before Committing

The staging area lets you review exactly what you're about to commit:

BASH

# Stage some changes
git add index.html styles.css

# Review what you're about to commit
git diff --staged

# Looks good? Commit it!
git commit -m "Update homepage layout"

Reason 4: Incremental Staging

You can stage parts of a file, not just entire files (we'll learn this soon):

BASH

# Stage only some changes from a file
git add -p large-file.js

# Git asks about each change:
# "Stage this hunk? [y,n,q,a,d,/,e,?]"

Understanding File States

Files in your Git repository can be in several states:

Untracked

Files that Git isn't watching yet. Brand new files you just created.

BASH

# Create a new file
echo "New file" > newfile.txt

# Git sees it but isn't tracking it yet
git status
# Untracked files:
#   newfile.txt

Unmodified

Files that Git is tracking but haven't been changed since the last commit.

Modified

Files that have been changed but not yet staged.

BASH

# Edit an existing file
echo "More content" >> index.html

# Git sees it's changed
git status
# Changes not staged for commit:
#   modified:   index.html

Staged

Files that have been marked to go into the next commit.

BASH

# Stage the change
git add index.html

# Now it's staged
git status
# Changes to be committed:
#   modified:   index.html

The Lifecycle

Files move through these states:

TEXT

Untracked → [git add] → Staged → [git commit] → Unmodified
                                                        ↓
                                                    [edit file]
                                                        ↓
                                                    Modified → [git add] → Staged

Git Status: A Deep Dive

git status is your window into the three trees. Let's learn to read it like a pro.

Understanding the Output

BASH

git status

TEXT

On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   contact.html
        modified:   index.html

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:   styles.css
        deleted:    old-page.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        script.js
        images/logo.png

Let's break this down:

Changes to be committed (Staged):

These changes are in the staging area and will be included in your next commit:

contact.html - New file, staged
index.html - Modified file, staged

Changes not staged for commit (Modified):

These files are tracked by Git and have been modified, but the changes aren't staged:

styles.css - Changed but not staged
old-page.html - Deleted but deletion not staged

Untracked files:

These files exist in your working directory but Git isn't tracking them:

script.js - New file, not yet added to Git
images/logo.png - New file in subdirectory

Short Status

For a more compact view:

BASH

git status -s
# or
git status --short

TEXT

A  contact.html
M  index.html
 M styles.css
 D old-page.html
?? script.js
?? images/

The status codes:

?? - Untracked files
A - Added (new file, staged)
M - Modified and staged (left column)
M - Modified but not staged (right column)
MM - Modified, staged, then modified again
D - Deleted but not staged
D - Deleted and staged

Advanced Staging Techniques

Stage Specific Files

BASH

# Stage one file
git add index.html

# Stage multiple specific files
git add index.html styles.css script.js

# Stage all files in a directory
git add src/

# Stage all JavaScript files
git add *.js

Stage All Changes

BASH

# Stage everything in current directory and subdirectories
git add .

# Stage all changes in entire repository (from any directory)
git add -A
# or
git add --all

# Stage modified and deleted files (not new files)
git add -u
# or
git add --update

Interactive Staging

Stage parts of files selectively (patch mode):

BASH

git add -p filename
# or
git add --patch filename

Git will show each change and ask what to do:

TEXT

Stage this hunk [y,n,q,a,d,/,s,e,?]?

y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any remaining hunks
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any later hunks in the file
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help

✂️ Patch Mode Power

Patch mode is incredibly powerful! You can commit different parts of the same file in separate commits. This is perfect when you made multiple unrelated changes to one file.

Stage and Commit in One Command

BASH

# Stage all tracked files and commit
git commit -a -m "Update multiple files"
# or
git commit -am "Update multiple files"

# WARNING: This only stages TRACKED files
# It won't stage new (untracked) files!

Unstaging Changes

Sometimes you stage something by accident. Here's how to unstage:

Modern Way (Git 2.23+)

BASH

# Unstage a specific file
git restore --staged filename.txt

# Unstage all files
git restore --staged .

Traditional Way

BASH

# Unstage a specific file
git reset HEAD filename.txt

# Unstage all files
git reset HEAD

Important: Unstaging doesn't discard your changes! It just moves them from the staging area back to the working directory. Your modifications are still there.

The Difference Between Unstaging and Discarding

BASH

# UNSTAGE: Remove from staging area, keep changes
git restore --staged file.txt
# Changes still in working directory

# DISCARD: Throw away changes completely (DANGEROUS!)
git restore file.txt
# Changes are gone forever!

Warning: git restore file.txt (without --staged) permanently deletes your uncommitted changes! Make sure you really want to discard them.

Viewing Changes

See Unstaged Changes

BASH

# Show changes not yet staged
git diff

# Show changes for a specific file
git diff filename.txt

This compares your working directory with the staging area. It shows what you changed but haven't staged yet.

See Staged Changes

BASH

# Show changes that are staged
git diff --staged
# or
git diff --cached

# Show staged changes for a specific file
git diff --staged filename.txt

This compares the staging area with the last commit. It shows exactly what will be in your next commit.

See All Changes

BASH

# Show all changes (staged and unstaged)
git diff HEAD

# This compares working directory with last commit

Comparison Table

TEXT

Command              | Compares
---------------------|----------------------------------
git diff             | Working Dir ↔ Staging Area
git diff --staged    | Staging Area ↔ Last Commit (HEAD)
git diff HEAD        | Working Dir ↔ Last Commit (HEAD)

🔍 Always Review Before Committing

Make it a habit to run git diff --staged before git commit. This shows you exactly what you're about to commit and helps catch mistakes!

Practical Scenarios

Scenario 1: Selective Staging

You worked on three different things and want to commit them separately:

BASH

# You modified:
# - auth.js (login bug fix)
# - dashboard.js (new feature)
# - utils.js (refactoring)

# Commit 1: Bug fix
git add auth.js
git commit -m "Fix login redirect bug"

# Commit 2: New feature
git add dashboard.js
git commit -m "Add user dashboard with analytics"

# Commit 3: Refactoring
git add utils.js
git commit -m "Refactor date formatting utilities"

# Result: 3 clear, focused commits instead of 1 messy one

Scenario 2: Staging Part of a File

You made two unrelated changes to the same file:

BASH

# app.js has:
# - Bug fix in lines 10-15
# - New feature in lines 50-70

# Stage only the bug fix
git add -p app.js

# When Git shows the bug fix section:
# y (yes, stage this)

# When Git shows the feature section:
# n (no, don't stage this)

# Commit just the bug fix
git commit -m "Fix null pointer exception in login"

# Later, stage and commit the feature
git add app.js
git commit -m "Add password strength indicator"

Scenario 3: Reviewing Before Committing

BASH

# Make some changes
git add .

# Wait, what did I just stage?
git diff --staged

# Oh no, I staged debug code by accident!
git restore --staged debug.js

# Now check again
git status

# Looks good, commit
git commit -m "Update homepage layout"

Scenario 4: Mixed State

Same file can be both staged and modified:

BASH

# Edit index.html
echo "Line 1" >> index.html

# Stage it
git add index.html

# Edit it again
echo "Line 2" >> index.html

# Now check status
git status
# Changes to be committed:
#   modified:   index.html
#
# Changes not staged for commit:
#   modified:   index.html

# The first change is staged, the second isn't!

# To commit both:
git add index.html
git commit -m "Update index.html"

# Or to commit only the first change:
git commit -m "Add Line 1 to index.html"
# (Line 2 remains uncommitted)

Staging Deletions and Renames

Deleting Files

BASH

# Wrong way: Just deleting the file
rm oldfile.txt
git add oldfile.txt  # This stages the deletion

# Right way: Using git rm
git rm oldfile.txt   # Deletes AND stages in one command

# To delete from Git but keep in working directory
git rm --cached oldfile.txt

Moving/Renaming Files

BASH

# Wrong way: Manual move
mv old.txt new.txt
git add old.txt new.txt

# Right way: Using git mv
git mv old.txt new.txt  # Moves AND stages in one command

Git is smart about moves: Even if you manually move a file, Git can usually detect that it was renamed (not deleted and recreated) as long as the content is similar enough.

Practice Staging Commands

Try these commands to practice working with the staging area:

Practice Staging Operations

Experiment with staging and viewing changes

Try these examples:

Staging Best Practices

1. Check Status Frequently

Run git status often to understand what state your files are in.

2. Review Before Staging

BASH

# See what changed
git diff

# Looks good? Stage it
git add file.txt

3. Review Before Committing

BASH

# What am I about to commit?
git diff --staged

# Perfect? Commit it
git commit -m "Message"

4. Stage Logically Related Changes

Each commit should be a logical unit. Use selective staging to group related changes together.

5. Don't Stage Everything Blindly

Be careful with:

BASH

git add .

This stages everything. Make sure you actually want to commit all changes! Always run git status first.

6. Use .gitignore

Don't stage files that shouldn't be in version control:

.gitignore

node_modules/
.env
.DS_Store
*.log
dist/

7. Commit Often, Perfect Later

It's okay to make frequent small commits. You can always clean up your history later (advanced topic).

Common Staging Mistakes

Mistake 1: Committing Sensitive Data

Problem: Accidentally staged passwords or API keys

Prevention:

BASH

# Add sensitive files to .gitignore FIRST
echo ".env" >> .gitignore
echo "secrets.json" >> .gitignore

# Then stage everything else
git add .

Mistake 2: Staging Debug Code

Problem: Staged files with console.log() or debug statements

Solution:

BASH

# Review what you're staging
git diff --staged

# Oops, debug code!
git restore --staged debug-file.js
# Remove the debug statements
# Stage again
git add debug-file.js

Mistake 3: Forgot to Stage New Files

Problem: Committed but new files weren't included

Solution:

BASH

# Always check status before committing
git status

# See untracked files? Add them!
git add new-file.js

# Or use commit --amend to add to last commit
git add new-file.js
git commit --amend --no-edit

Command Reference

Here's a quick reference of all staging commands:

BASH

# Staging Files
git add filename              # Stage specific file
git add .                     # Stage all in current directory
git add -A                    # Stage all changes everywhere
git add -u                    # Stage modified/deleted (not new)
git add *.js                  # Stage all JavaScript files
git add -p filename           # Interactive staging (patch mode)

# Unstaging Files
git restore --staged filename # Unstage specific file
git restore --staged .        # Unstage everything
git reset HEAD filename       # Unstage (traditional way)

# Viewing Changes
git status                    # See file states
git status -s                 # Short status
git diff                      # Unstaged changes
git diff --staged             # Staged changes
git diff HEAD                 # All changes

# Discarding Changes (DANGEROUS!)
git restore filename          # Discard unstaged changes
git restore .                 # Discard all unstaged changes

# Deleting and Moving
git rm filename               # Delete and stage
git rm --cached filename      # Remove from Git, keep file
git mv oldname newname        # Move/rename and stage

Key Takeaways

Git uses three trees: Working Directory, Staging Area, and Repository
The staging area gives you precise control over what goes into each commit
Files can be untracked, unmodified, modified, or staged
git status shows you the state of all three trees
git add moves changes to the staging area
git restore --staged unstages changes without discarding them
git diff shows unstaged changes
git diff --staged shows what will be in the next commit
You can stage part of a file with git add -p
Always review changes before staging and before committing

What's Next?

🎯 Practice Assignment

Before the next lesson, practice working with the staging area:

Create multiple files and make changes to existing ones
Practice staging files selectively (not with git add .)
Use git diff and git diff --staged to review changes
Practice unstaging files with git restore --staged
Try patch mode (git add -p) on a file with multiple changes
Create commits with only related changes grouped together

Test Your Understanding of the Staging Area

Question 1 of 4

What is the staging area in Git?

Current Score0 / 0

Git's Three-Tree Architecture

The Three Trees

How They Work Together

Why Does the Staging Area Exist?

Reason 1: Selective Commits

Reason 2: Logical Grouping

Reason 3: Review Before Committing

Reason 4: Incremental Staging

Understanding File States

Untracked

Unmodified

Modified

Staged

The Lifecycle

Git Status: A Deep Dive

Understanding the Output

Short Status

Advanced Staging Techniques

Stage Specific Files

Stage All Changes

Interactive Staging

Stage and Commit in One Command

Unstaging Changes

Modern Way (Git 2.23+)

Traditional Way

The Difference Between Unstaging and Discarding

Viewing Changes

See Unstaged Changes

See Staged Changes

See All Changes

Comparison Table

Practical Scenarios

Scenario 1: Selective Staging

Scenario 2: Staging Part of a File

Scenario 3: Reviewing Before Committing

Scenario 4: Mixed State

Staging Deletions and Renames

Deleting Files

Moving/Renaming Files

Practice Staging Commands

Practice Staging Operations

Staging Best Practices

1. Check Status Frequently

2. Review Before Staging

3. Review Before Committing

4. Stage Logically Related Changes

5. Don't Stage Everything Blindly

6. Use .gitignore

7. Commit Often, Perfect Later

Common Staging Mistakes

Mistake 1: Committing Sensitive Data

Mistake 2: Staging Debug Code

Mistake 3: Forgot to Stage New Files

Command Reference

Key Takeaways

What's Next?

Test Your Understanding of the Staging Area

What is the staging area in Git?

Know someone who'd find this guide helpful? Please share!

Never Miss a New Git & GitHub Tutorial

You might also like

UI Components

Developer Tools

HTML Game

Join Our Web Development Training Program

Join Our Social Communities

Git & Github Tutorials

The Staging Area

Git's Three-Tree Architecture

The Three Trees

How They Work Together

Why Does the Staging Area Exist?

Reason 1: Selective Commits

Reason 2: Logical Grouping

Reason 3: Review Before Committing

Reason 4: Incremental Staging

Understanding File States

Untracked

Unmodified