Concept and mechanism
The working tree contains files being edited. The index, also called the staging area, contains the version prepared for the next commit. A commit records an index snapshot and references to its parents. After git add, another edit does not automatically change the staged version. The same file can therefore have staged and unstaged changes. This separation supports small, coherent commits but requires reviewing the actual content before recording it.
Guided application
In a local exercise, change two functions and stage only the intended fix. Use git diff to compare working tree with index and git diff --cached to compare index with HEAD. Also review untracked files, which do not appear as content differences in already tracked files. To remove a file from the next commit while keeping edits, use git restore --staged -- path. Confirm status and staged differences again. Do not use a command that restores the working tree when you only mean to change commit selection.
You staged config.yml and then removed a password from the local file. The index may still contain it. Review and update staged content before committing.
Common pitfalls
Confusing the editor-visible version with the staged version; assuming.gitignore stops tracking already versioned files.
Related topics: Branches, merge, and rebase · Remotes and coordinated publication
Review the staged snapshot, not just the editor state.
Reference: Git: comparing changes · Git 2.56; workflow concepts compatible with modern Git 2.x