Staging Area

Q: What is the difference between staged and unstaged changes?

Staged changes have been added with git add and will be included in the next commit. Unstaged changes are edits in your working directory that Git has noticed but won't commit until you stage them.

Q: Why is the staging area also called the index?

Git stores the staging area in a file named .git/index, so Git's commands and documentation often use the word index, as in git diff --cached. Staging area, index, and cache all refer to the same thing.

Q: Can I commit without using the staging area?

Mostly, yes. git commit -a automatically stages every modified tracked file before committing, but it still skips new untracked files, which must be added with git add first.

Updated September 30, 20262 min read

In short

The staging area in Git is a holding zone between your files and the next commit, where you place exactly the changes you want that commit to include.

What is the staging area in Git?

The staging area is where Git collects the changes that will go into your next commit. When you edit a file, the change exists only in your working directory, the ordinary project folder you see on disk. Running git add records the current version of that file in the staging area, and git commit then saves everything that is staged, and nothing else, as a new snapshot.

Internally, the staging area is a single file, .git/index, which is why Git's documentation also calls it the index. It lists every tracked file together with the version that will be committed, so if you keep editing a file after staging it, the newer edits stay unstaged until you run git add again. git status shows both groups, under 'Changes to be committed' and 'Changes not staged for commit'.

The staging area is like a packing table next to a shipping box: you gather items from around the room, check them on the table, and only then seal what is on the table into the box. This lets you split an afternoon of mixed edits into several small, focused commits. git add -p goes further and lets you stage only some of the changes inside a single file.

The staging area is often confused with a commit or a stash. Staged changes are only a draft of the next commit and are not yet part of the project history, while a commit is a permanent snapshot. A stash, made with git stash, is different again: it sets unfinished work aside on a separate shelf and cleans the working directory. To take a file out of the staging area without losing your edits, use git restore --staged <file>.

Key takeaways

The staging area holds the changes that will go into the next commit.
git add stages changes, and git commit saves only what is staged.
Git stores the staging area in the .git/index file, so it is also called the index.
git add -p stages part of a file, which helps keep commits small and focused.
git restore --staged <file> unstages a file while keeping your edits.

Example

Staging exactly what you want to commitbash

# Edit two files, then stage only one of them
git add src/login.ts
git status
#   Changes to be committed:        modified: src/login.ts
#   Changes not staged for commit:  modified: src/styles.css

# Stage only some of the changes inside a file, hunk by hunk
git add -p src/styles.css

# Review exactly what the next commit will contain, then commit it
git diff --staged
git commit -m "Fix login form validation"

# Unstage a file but keep your edits
git restore --staged src/styles.css

Readers ask

What is the difference between staged and unstaged changes?

Staged changes have been added with git add and will be included in the next commit. Unstaged changes are edits in your working directory that Git has noticed but won't commit until you stage them.

Why is the staging area also called the index?

Git stores the staging area in a file named .git/index, so Git's commands and documentation often use the word index, as in git diff --cached. Staging area, index, and cache all refer to the same thing.

Can I commit without using the staging area?

Mostly, yes. git commit -a automatically stages every modified tracked file before committing, but it still skips new untracked files, which must be added with git add first.