ACCELERATED REVIEWS D197 / FREE PREVIEW
D197 Version Control - Free Preview
The three versions of your file
Accelerated Reviews teaches the reason behind each command. This sample is from an independent Version
Control study guide with six sequential local labs, twenty original practice questions, and explained solutions. It is
not affiliated with WGU and contains no assessment answers or submission template. Use your current course
materials for assessed requirements.
Git can hold three relevant versions of a tracked file at once: the latest recorded version in HEAD, the content
staged for the next commit, and the working file you are editing. These need not be identical. Understanding that
distinction is more valuable than memorizing "add, commit, push" as a single ritual.
A complete worked example
Imagine notes.txt contains Topic: branches in the latest commit. You add Review: merging and stage the file.
Then you add Practice: conflicts but do not stage again.
Location File content includes
Latest commit Topic: branches
Staging area Topic: branches; Review: merging
Working file Topic: branches; Review: merging; Practice: conflicts
If you commit now, Git records the staging-area version. The practice sentence remains an unstaged working edit.
Saving the file in your editor did not update the staging area automatically. A single file can therefore be both
staged and modified.
To inspect this situation in an existing practice repository, use:
git status --short
git diff --staged
git diff
The staged diff compares the index with HEAD and shows the review sentence. The ordinary diff compares the
working tree with the index and shows the practice sentence. Short status may show MM notes.txt: the first
position reports a staged modification, and the second reports a working-tree modification.
Before recording the change, decide what belongs together. If both sentences form one coherent update, stage
the file again and inspect the staged diff. If the review sentence is complete but the practice sentence is
unfinished, commit the staged review alone. Git gives you control over this boundary; use it deliberately.
Common mistake: Assuming add means "include every future edit to this file." Add captures the current content.
If you change the file afterward, make another explicit staging decision.
Edition 1.0 - October 2026 1
D197 Version Control - Free Preview
The three versions of your file
Accelerated Reviews teaches the reason behind each command. This sample is from an independent Version
Control study guide with six sequential local labs, twenty original practice questions, and explained solutions. It is
not affiliated with WGU and contains no assessment answers or submission template. Use your current course
materials for assessed requirements.
Git can hold three relevant versions of a tracked file at once: the latest recorded version in HEAD, the content
staged for the next commit, and the working file you are editing. These need not be identical. Understanding that
distinction is more valuable than memorizing "add, commit, push" as a single ritual.
A complete worked example
Imagine notes.txt contains Topic: branches in the latest commit. You add Review: merging and stage the file.
Then you add Practice: conflicts but do not stage again.
Location File content includes
Latest commit Topic: branches
Staging area Topic: branches; Review: merging
Working file Topic: branches; Review: merging; Practice: conflicts
If you commit now, Git records the staging-area version. The practice sentence remains an unstaged working edit.
Saving the file in your editor did not update the staging area automatically. A single file can therefore be both
staged and modified.
To inspect this situation in an existing practice repository, use:
git status --short
git diff --staged
git diff
The staged diff compares the index with HEAD and shows the review sentence. The ordinary diff compares the
working tree with the index and shows the practice sentence. Short status may show MM notes.txt: the first
position reports a staged modification, and the second reports a working-tree modification.
Before recording the change, decide what belongs together. If both sentences form one coherent update, stage
the file again and inspect the staged diff. If the review sentence is complete but the practice sentence is
unfinished, commit the staged review alone. Git gives you control over this boundary; use it deliberately.
Common mistake: Assuming add means "include every future edit to this file." Add captures the current content.
If you change the file afterward, make another explicit staging decision.
Edition 1.0 - October 2026 1
