The working tree contains editable files; the index selects the next snapshot; a commit records that snapshot. These can differ simultaneously.
Before you start
You should understand commits, branches, the working tree and the staging area. Draw the commit graph before changing history. Try commands in a disposable repository with a clean working tree so you can observe exactly which references and files each operation changes.
The practical goal is to reason through this situation: A file can have staged changes plus additional unstaged edits. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Inspect editable content
The working file may include changes not staged yet.
Step 2: Inspect the selected snapshot
The index contains what the next commit will record.
Step 3: Review both differences
Use staged and unstaged diffs separately before committing.
Worked scenario
A file can have staged changes plus additional unstaged edits.
git status --short
git diff
git diff --cachedAfter staging version A, editing the file into version B does not automatically update the index. The commit still records A unless the newer edits are staged. These inspection commands reveal the two independent comparisons without changing either snapshot.
Common mistake
Assuming commit includes every visible edit can omit recent work.
Verify the behavior
Stage a disposable file, edit it again and predict each diff before reading it.
Interview exercise
Inspect the next commit.
Answer and reasoning
Review staged diff separately from working-tree diff, then stage only the intended final content.
Continue learning
Compare the scenario with the Git and CI/CD interview questions and test your understanding with the Git and CI/CD MCQs. For terminology and implementation details, consult the reference material.