ACCELERATED REVIEWS / STUDY COLLECTION
D197
Version Control
Six local Git labs - from snapshots to collaboration
20 WHY APPLY
original questions explained solutions worked examples
Independent course-topic review. Original learning material.
Not affiliated with or endorsed by Western Governors University.
EDITION 1.0 | 29 OCTOBER 2026
,ACCELERATED REVIEWS D197 / INDEPENDENT STUDY GUIDE
Contents
How to use this guide 3
Lesson 1 - Know where your change lives 3
Lesson 2 - Inspect, stage, and record a coherent change 4
Lesson 3 - Branch deliberately and read the history 5
Lesson 4 - Resolve the meaning of a conflict 6
Lesson 5 - Separate local history from shared history 7
Lesson 6 - Recover carefully and preserve evidence 8
Quick reference 9
Practice - 20 original questions 9
Solutions and reasoning 11
Glossary 13
References and scope 14
Edition 1.0 - October 2026 2
,ACCELERATED REVIEWS D197 / INDEPENDENT STUDY GUIDE
How to use this guide
Learn the state changes behind Git commands, then prove them in a small practice repository. This independent
topic review supports students studying Version Control. It is not affiliated with or endorsed by WGU and does not
reproduce an assessment, submission template, or grading rubric. Consult your current course materials for
assessment requirements. All scenarios and questions here are original.
Edition 1.0 - 29 October 2026. Commands use PowerShell and Git 2.28 or newer. Git commands also work in
common Unix shells; PowerShell file-writing commands require PowerShell. No online account, paid service,
credentials, or network connection is required for the labs.
Your three-session plan
• Session 1: Read lessons 1-2; complete labs 1-2. Explain working tree, staging area, and commit without looking.
Answer questions 1-6.
• Session 2: Read lessons 3-5; complete labs 3-5 in order. Sketch the branches and explain what changed locally
versus remotely. Answer questions 7-14.
• Session 3: Read lesson 6; complete lab 6. Answer questions 15-20, then explain every incorrect answer using
the solution section. Repeat weak skills in a new lab directory.
A correct command without an explanation is an unfinished learning goal. Keep a short error log: prediction,
observation, reason, and one new test. This is a study method, not an assessment-readiness score.
Lesson 1 - Know where your change lives
Git records project history as commits. A normal working repository has editable files (the working tree), a
proposed next snapshot (the index or staging area), and recorded history. HEAD usually points to the branch you
currently have checked out. A branch name identifies a commit; new commits normally advance that branch.
The staging area lets you choose a coherent change instead of committing every edit in the directory. Saving a file
in your editor changes the working tree. Staging captures that file's current content. Editing it again does not
automatically update the staged version. Committing records the staged content, not whatever happens to be
visible in your editor afterward.
Worked prediction
Suppose a tracked file contains version A in the latest commit. You edit it to B, stage it, and then edit it to C. The
recorded history still contains A, the index contains B, and the working file contains C. A commit now records B.
This is why a file can appear in both staged and unstaged sections of status.
Question Command Comparison
What changed after staging? git diff Working tree vs index
What will the next commit git diff --staged Index vs HEAD
record?
What tracked changes exist git diff HEAD Working tree vs HEAD
overall?
Edition 1.0 - October 2026 3
D197
Version Control
Six local Git labs - from snapshots to collaboration
20 WHY APPLY
original questions explained solutions worked examples
Independent course-topic review. Original learning material.
Not affiliated with or endorsed by Western Governors University.
EDITION 1.0 | 29 OCTOBER 2026
,ACCELERATED REVIEWS D197 / INDEPENDENT STUDY GUIDE
Contents
How to use this guide 3
Lesson 1 - Know where your change lives 3
Lesson 2 - Inspect, stage, and record a coherent change 4
Lesson 3 - Branch deliberately and read the history 5
Lesson 4 - Resolve the meaning of a conflict 6
Lesson 5 - Separate local history from shared history 7
Lesson 6 - Recover carefully and preserve evidence 8
Quick reference 9
Practice - 20 original questions 9
Solutions and reasoning 11
Glossary 13
References and scope 14
Edition 1.0 - October 2026 2
,ACCELERATED REVIEWS D197 / INDEPENDENT STUDY GUIDE
How to use this guide
Learn the state changes behind Git commands, then prove them in a small practice repository. This independent
topic review supports students studying Version Control. It is not affiliated with or endorsed by WGU and does not
reproduce an assessment, submission template, or grading rubric. Consult your current course materials for
assessment requirements. All scenarios and questions here are original.
Edition 1.0 - 29 October 2026. Commands use PowerShell and Git 2.28 or newer. Git commands also work in
common Unix shells; PowerShell file-writing commands require PowerShell. No online account, paid service,
credentials, or network connection is required for the labs.
Your three-session plan
• Session 1: Read lessons 1-2; complete labs 1-2. Explain working tree, staging area, and commit without looking.
Answer questions 1-6.
• Session 2: Read lessons 3-5; complete labs 3-5 in order. Sketch the branches and explain what changed locally
versus remotely. Answer questions 7-14.
• Session 3: Read lesson 6; complete lab 6. Answer questions 15-20, then explain every incorrect answer using
the solution section. Repeat weak skills in a new lab directory.
A correct command without an explanation is an unfinished learning goal. Keep a short error log: prediction,
observation, reason, and one new test. This is a study method, not an assessment-readiness score.
Lesson 1 - Know where your change lives
Git records project history as commits. A normal working repository has editable files (the working tree), a
proposed next snapshot (the index or staging area), and recorded history. HEAD usually points to the branch you
currently have checked out. A branch name identifies a commit; new commits normally advance that branch.
The staging area lets you choose a coherent change instead of committing every edit in the directory. Saving a file
in your editor changes the working tree. Staging captures that file's current content. Editing it again does not
automatically update the staged version. Committing records the staged content, not whatever happens to be
visible in your editor afterward.
Worked prediction
Suppose a tracked file contains version A in the latest commit. You edit it to B, stage it, and then edit it to C. The
recorded history still contains A, the index contains B, and the working file contains C. A commit now records B.
This is why a file can appear in both staged and unstaged sections of status.
Question Command Comparison
What changed after staging? git diff Working tree vs index
What will the next commit git diff --staged Index vs HEAD
record?
What tracked changes exist git diff HEAD Working tree vs HEAD
overall?
Edition 1.0 - October 2026 3
