Menu
Coddy logo textTech

The Staging Area

Part of the Version Control section of Coddy's Terminal journey — lesson 9 of 58.

Git does not commit every change automatically. Instead, you explicitly choose which changes go into the next snapshot. This two-step workflow is built around the staging area.

Think of it as a clipboard for the next commit. A file moves through three states:

  1. Working directory: where you edit files normally.
  2. Staging area: changes you have marked for the next commit.
  3. Repository: the permanent history, after you commit.

The point of staging is control. You can edit ten files, but stage only the two related to one bug fix, commit those, and then stage and commit the rest separately. Each commit ends up focused on one logical change.

You move files into staging with git add, and from staging into the repository with git commit.

challenge icon

Challenge

Beginner

The folder contains an untracked file app.txt. Initialize the repository, then run git status --short to confirm the file shows up as untracked.

Cheat sheet

Git uses a two-step workflow to create commits:

  1. Working directory – where you edit files
  2. Staging area – changes marked for the next commit
  3. Repository – permanent history after committing

Stage changes with git add, then save them to history with git commit. This lets you group related changes into focused commits even when multiple files have been edited.

Try it yourself

Terminal
quiz iconTest yourself

This lesson includes a short quiz. Start the lesson to answer it and track your progress.

All lessons in Version Control