Module 3 Lesson 1: Staging changes with git add
·DevOps

Module 3 Lesson 1: Staging changes with git add

Master the art of the Staging Area. Learn the different ways to use 'git add'—from staging individual files to interactive patching.

Module 3 Lesson 1: Staging changes with git add

As we learned in Module 1, Git doesn't automatically save every change you make to a file. You must explicitly tell Git which changes you want to include in your next snapshot. This process is called Staging.

In this lesson, we explore the git add command and the different ways you can control your staging area.


1. The Basic Command

The most common way to stage a file is by its name:

git add index.html

You can also stage multiple files at once:

git add index.html styles.css main.js

2. Staging Everything

If you have changed 20 files and want to stage them all, typing their names is slow. Use these shortcuts:

  • git add .: Stages all changes in the current directory and its subdirectories.
  • git add -A: Stages all changes in the entire repository, including file deletions.

Warning: The "Dirty" Add

Be careful with git add .! If you accidentally created a temporary file or left a secrets file unignored, git add . will happily stage it for you. Always check git status before adding.


3. Advanced Staging: Interactive and Patching

One of Git's most powerful features is the ability to stage only parts of a file. This allows you to keep your commits focused even if you've been working on multiple things at once.

git add -p (The Patch Flag)

This command opens an interactive prompt. Git shows you a "hunk" (a small block of changed code) and asks: "Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? "

  • y/n: Yes or No for this specific block.
  • q: Quit (don't stage anything else).
  • s: Split the current hunk into smaller ones (if possible).
graph TD
    File["Main.js (3 different fixes)"] --> GitAddP["git add -p"]
    GitAddP --> Hunk1["Hunk 1: Typo Fix"]
    GitAddP --> Hunk2["Hunk 2: New Feature"]
    GitAddP --> Hunk3["Hunk 3: Console Log Removal"]
    
    Hunk1 -- "y" --> Staged["Staging Area (Ready for Commit)"]
    Hunk2 -- "n" --> Local["Working Directory (Stored for Later)"]
    Hunk3 -- "y" --> Staged

4. Unstaging Files

What if you stage a file by mistake? You can "undo" the add (move the file back to the working directory) without losing your work:

# In modern Git (2.23+)
git restore --staged <file>

# In older Git
git reset HEAD <file>

Lesson Exercise

Goal: Practice granular staging.

  1. Open a file in your git-practice repo.
  2. Add three different lines of text at the top, middle, and bottom.
  3. Save the file.
  4. Run git add -p.
  5. Try to stage only the top and bottom lines, but not the middle line.
  6. Run git status and git diff --staged to verify that only parts of the file are ready for commit.

Observation: You'll see that Git sees your file as a collection of changes, not just a static object. This control is what makes Git history so clean.


Summary

In this lesson, we established:

  • git add moves changes from the Working Directory to the Staging Area.
  • git add . is a fast but "blunt" tool; use it with caution.
  • git add -p allows for precise, line-by-line control over what gets committed.
  • git restore --staged is the "undo" button for the staging area.

Next Lesson: Once your changes are staged, it's time to seal the envelope. We're going to master git commit.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn