Version Control Exercises

You understand how Git tracks changes. You've created commits, viewed diffs, tested ideas on branches, pushed to GitHub, and created pull requests. That's real knowledge -- but there's a gap between knowing the commands and reaching for them instinctively when your AI-generated code breaks at 11pm.

These exercises close that gap. Fifteen hands-on challenges across six modules practice the three skills that make Git second nature: repository management (building clean, well-structured projects), problem diagnosis (reading Git output to find and fix broken state), and professional workflows (PRs, transparency, and reusable patterns). Every exercise uses a real Git repository -- you'll run actual commands, not answer theory questions.

Download Exercise Files

Download Version Control Exercises (ZIP)

After downloading, unzip the file. Each exercise has its own folder with an INSTRUCTIONS.md and any starter files you need.

If the download link doesn't work, visit the repository releases page directly.

---

How to Use These Exercises

The workflow for every exercise is the same:

1. Open the exercise folder in your terminal
2. Read the INSTRUCTIONS.md -- it tells you what's broken or what to build
3. Read the walkthrough below for context and learning objectives
4. For Debug exercises: run setup.sh first to create the broken state
5. Work through the exercise -- run real Git commands
6. Reflect using the questions provided -- this is where the real learning happens

You don't need to complete all 15 in one sitting. Work through one module at a time. Each module builds on the workflows from specific chapter lessons.

---

Key Differences from Chapter Lessons

In Lessons 1-6, you learned each Git workflow in isolation with guided walkthroughs. These exercises are different in three ways:

• No step-by-step instructions. The exercises describe the scenario, the data, and the goal. You decide the approach, write the prompts, and handle unexpected situations yourself.
• Build + Debug pairing. Every module has a Build exercise (create something from scratch) and a Debug exercise (find and fix problems in broken state). Debugging a broken repository develops different skills than building a clean one -- you learn to read Git output critically, compare expected vs. actual state, and trace errors back to their root cause.
• Increasing independence. Modules 1-2 provide starter prompts to scaffold your learning. Modules 3-6 remove the scaffolding. Capstones remove everything -- you design the entire approach.

By Module 6, you should be able to face a new Git problem and instinctively reach for the right diagnostic command without needing to review the chapter lessons.

---

Tool Guide

• Claude Code -- Terminal-based, best for running Git commands and diagnosing problems. Required for all exercises that involve running commands.
• Cowork -- Desktop app, best for understanding concepts and planning your approach. Use it when you need to think through a strategy before executing.
• Most exercises require the terminal. Use Cowork for planning and understanding, Claude Code for execution.

---

The Git Safety Framework

Use this framework for every exercise:

1. Assess -- What's the current state? (git status, git log, git branch)
2. Plan -- What needs to happen? What's the safest path?
3. Protect -- Create a safety net before risky changes (commit, branch, backup)
4. Execute -- Run the commands with intention
5. Verify -- Did it work? Check status, diff, log
6. Document -- Record what happened and why (commit messages, workflow docs)

This framework isn't just for exercises -- it's how professional developers approach every Git operation. When something goes wrong and you feel the urge to start typing commands frantically, stop and start at step 1 instead. The exercises will test whether you follow this framework or skip straight to execution.

---

Assessment Rubric

For each exercise, evaluate yourself on:

Criteria	Beginner (1)	Developing (2)	Proficient (3)	Advanced (4)
Command Accuracy	Runs wrong commands, needs multiple attempts	Gets right command but wrong flags/arguments	Correct commands on first try for common scenarios	Handles edge cases and combines commands fluently
Safety Awareness	Makes changes without checking state first	Checks status but doesn't create safety nets	Commits/branches before risky operations consistently	Anticipates risks and creates preemptive safety measures
Diagnosis Skill	Can't interpret git output or error messages	Understands basic status output, struggles with complex state	Reads git output fluently, diagnoses common problems	Diagnoses unusual scenarios, explains root causes clearly
Workflow Discipline	No consistent pattern, ad-hoc commands	Follows basic add-commit cycle	Uses full workflow (status-diff-add-commit-push) consistently	Adapts workflow to context, documents decisions
Recovery Confidence	Panics at errors, afraid to experiment	Uses restore/reset but hesitantly	Recovers from common mistakes quickly and confidently	Handles complex recovery (merge conflicts, history rewriting) calmly

---

Module 1: Repository Foundations

Core Skill: Building clean, well-structured repositories from the start

Lessons 1-2 taught you how to initialize repos, stage files selectively, create meaningful commits, and protect secrets with .gitignore. These exercises push those skills into realistic scenarios where the project structure is messier and the decisions about what to track are less obvious than the lesson examples.

Exercise 1.1 -- Project Kickoff (Build)

The Problem: Open the module-1-repo-foundations/exercise-1.1-project-kickoff/ folder. You'll find a weather-tracker/ project with Python source code in src/app.py, data files in data/, a configuration file src/config.json containing FAKE API secrets, and personal notes in notes/todo.txt. Nothing is under version control yet. Your job is to turn this into a clean, well-organized Git repository.

Your Task: Initialize Git, create a .gitignore that protects the config file with secrets and the personal notes, stage files selectively (not with git add .), and build a commit history of 3-4 meaningful commits -- not one giant "initial commit" dump. Think about how someone reading your commit log in 3 months would understand the project's setup.

Key Decisions You'll Face:

• Which files go in .gitignore and which get tracked? The data/ folder has real data files -- should they be in version control?
• What order should you commit files in? There's a logical progression from project structure to source code to data.
• How specific should your commit messages be? "Add weather tracker source code" vs. "Initial commit" -- which helps your future self?

What You'll Learn:

• Why selective staging beats git add . -- you control exactly what enters each commit rather than dumping everything in at once
• How .gitignore protects secrets from ever entering version control, which matters because secrets in Git history persist even after deletion
• What makes commit messages useful 3 months later: describing the purpose of each commit, not just listing the files changed

Starter Prompt (Intentionally Vague):

"Set up Git for this project."

Better Prompt (Build Toward This):

After examining the project structure with ls -R weather-tracker/: "Initialize a Git repository in this weather-tracker folder. First, create a .gitignore that excludes src/config.json (it contains API secrets) and the notes/ folder (personal). Then create 3-4 meaningful commits that build up the project logically: start with the .gitignore and project structure, then add the source code, then add the data files. Each commit should have a message that explains why, not just what."

Reflection Questions:

1. What would happen if you had run git add . before creating the .gitignore? Would the secrets already be tracked?
2. Could someone reading only your commit log (without looking at the code) understand how the project was built?
3. If a teammate cloned your repo tomorrow, what files would be missing from their copy -- and would they know those files are needed?

---

Exercise 1.2 -- Repo Rescue (Debug)

The Problem: Open the module-1-repo-foundations/exercise-1.2-repo-rescue/ folder and run setup.sh. This creates a repository with three problems: an .env file containing FAKE API keys was committed to history, the commit messages are useless ("fix", "stuff", "asdf"), and there is no .gitignore at all. Run git log and git status to see the full picture.

Your Task: Diagnose what went wrong by examining the commit history. Add a .gitignore that will prevent .env files from being tracked going forward. Note that simply adding .env to .gitignore doesn't remove it from history -- the file is already committed. Document what happened in a REMEDIATION.md file explaining the problems you found and the steps you took to fix them.

Investigation Commands:

• git log --oneline -- See the commit history (notice the useless messages)
• git show <commit-hash> -- Inspect individual commits to find what was committed
• git log --all --diff-filter=A -- .env -- Find exactly when the .env file was first added

What You'll Learn:

• How git log reveals project health -- bad commit messages are a symptom of careless version control habits
• Why secrets committed to history are dangerous even after deletion -- anyone who clones the repo gets the full history including the secrets
• How to add .gitignore retroactively and why it only prevents future tracking, not past commits

Starter Prompt (Intentionally Vague):

"Fix this repo."

Better Prompt (Build Toward This):

After running git log --oneline and git status: "This repo has three problems: committed secrets (.env with API keys), useless commit messages, and no .gitignore. First, create a .gitignore that prevents .env files from being tracked going forward. Then create a REMEDIATION.md documenting: (1) what secrets were exposed and in which commits, (2) why .gitignore alone doesn't remove them from history, (3) what steps would fully remove secrets from history if this were a real project."

Reflection Questions:

1. After adding .env to .gitignore, does git status still show the .env file? Why or why not?
2. If this repo were pushed to a public GitHub repository, who could access the API keys in the old commits?
3. What is the difference between removing a secret from the working directory versus removing it from Git history?

---

Module 2: Change Tracking & Recovery

Core Skill: Fearlessly experimenting because you can always recover

Lessons 2-3 taught you how to view changes with git diff, undo mistakes with git restore, and use branches for safe experimentation. These exercises put you in scenarios where AI-generated changes need careful review, selective staging, and confident recovery.

Exercise 2.1 -- AI Code Review Workflow (Build)

The Problem: Open the module-2-change-tracking/exercise-2.1-ai-review-workflow/ folder. You'll find a working todo-app/ with app.py (a simple task manager) and tasks.json (sample data). The app works correctly as-is. Your job is to improve it in 3 rounds, using AI to generate changes each round -- but with disciplined review between each round.

Your Task: In each of the 3 rounds: (1) ask Claude Code to make one improvement (add a feature, refactor a function, improve error handling), (2) use git diff to review every change before committing, (3) use git restore to discard any changes you don't want, (4) use selective git add to stage only the good changes, (5) commit with a message explaining what you kept and why. After 3 rounds, your commit history should tell the story of intentional, reviewed improvements.

What You'll Learn:

• The review-before-commit discipline that prevents AI disasters -- you see exactly what changed before it becomes permanent
• How selective staging gives you granular control over which AI changes you accept and which you discard
• Why small iterative commits beat one big dump -- each commit is a verified checkpoint you can return to if the next round breaks something

Starter Prompt (Intentionally Vague):

"Improve this todo app."

Better Prompt (Build Toward This):

After reading app.py to understand its current features: "I want to improve this todo app in 3 rounds. Round 1: Add a 'priority' field to tasks (high/medium/low). After making changes, I'll review with git diff before committing. Don't make any changes beyond adding priority support -- I want to review one feature at a time."

Reflection Questions:

1. In which round did git diff reveal a change you didn't want? What would have happened if you had committed without reviewing?
2. How did selective staging (adding specific files or hunks) change your relationship with AI-generated code?
3. Looking at your 3-commit history, could a reviewer understand your decision-making process from the commit messages alone?

---

Exercise 2.2 -- Recovery Room (Debug)

The Problem: Open the module-2-change-tracking/exercise-2.2-recovery-room/ folder. You'll find three sub-scenarios, each with its own setup.sh. Run each setup to create a different broken state: (A) AI made a mess of unstaged changes across 4 files -- some changes are good, others are broken, (B) you accidentally staged test files alongside production code and need to unstage selectively, (C) you committed a broken version and need to undo the commit without losing the good changes from the commit before it.

Your Task: Fix each scenario using the appropriate recovery tool. Scenario A requires git restore on specific files (keep the good changes, discard the bad). Scenario B requires git restore --staged to unstage files without discarding changes. Scenario C requires git revert to undo the bad commit while preserving history.

The Recovery Decision Tree:

Is the change committed?
├── Yes → git revert (creates an undo commit)
└── No → Is the change staged?
    ├── Yes → git restore --staged (unstages, keeps changes in working dir)
    └── No → git restore (discards changes from working directory)

What You'll Learn:

• When to use git restore (unstaged changes you want to discard) vs. git restore --staged (staged changes you want to unstage) vs. git revert (committed changes you want to undo)
• Why understanding the three stages (working directory, staging area, committed history) makes recovery instinctive rather than frightening
• That Git's recovery tools are designed for exactly these situations -- making mistakes is expected, and every stage has a matching undo command

Starter Prompt (Intentionally Vague):

"Undo these changes."

Better Prompt (Build Toward This):

After running git status and git diff in Scenario A: "There are changes across 4 files. I want to keep the changes in app.py and utils.py but discard the changes in config.py and test_broken.py. Use git restore to discard only the files I don't want, leaving the good changes intact. Then verify with git status that only the intended files still show as modified."

Reflection Questions:

1. Which recovery scenario felt most stressful? Did the stress decrease once you understood which command to use?
2. In Scenario C, why is git revert safer than git reset --hard for undoing a commit?
3. Could you now recover from any of these three situations without looking up the commands? What made the difference?

---

Module 3: Branch Strategies

Core Skill: Testing multiple ideas safely without risking working code

Lesson 3 taught you how branches create isolated workspaces for experiments. These exercises challenge you to use branches strategically -- comparing multiple approaches, untangling messes, and making decisions about which code to keep.

Exercise 3.1 -- Three Approaches (Build)

The Problem: Open the module-3-branch-strategies/exercise-3.1-three-approaches/ folder. You'll find sorting-challenge/ with an unsorted data.txt file, a requirements.md describing the sorting problem, and test-cases.txt with expected output for various inputs. You need to implement a sorting solution, but there are three valid approaches described in the requirements.

Your Task: Create three branches from main -- one for each approach. On each branch, implement the solution (with AI help if you want), test against the provided test cases, and commit working code. Switch between branches to compare the implementations. Merge the best approach into main, then delete the other two branches. Your final main should have a clean history showing only the winning approach.

Branch Naming Convention: Use descriptive names: approach-bubble-sort, approach-merge-sort, approach-insertion-sort -- not branch1, branch2, branch3. Good branch names are documentation.

What You'll Learn:

• How branches make comparison systematic rather than chaotic -- each approach lives in its own timeline, isolated from the others
• The discipline of test-before-merge: you don't merge an approach until it passes all test cases
• Why deleting losing branches keeps repos clean -- abandoned experiments shouldn't clutter your branch list

Reflection Questions:

1. How did you decide which approach was "best"? Was it code simplicity, performance, or how well it handled the test cases?
2. Did working on one branch influence your approach on another? How did isolation help or hinder that?
3. After merging the winner, did the final main branch history tell a clear story -- or did it include merge noise?

---

Exercise 3.2 -- Branch Tangle (Debug)

The Problem: Open the module-3-branch-strategies/exercise-3.2-branch-tangle/ folder and run setup.sh. This creates a repo with tangled branches: someone committed feature code to main by accident, left an orphaned branch old-feature with 2 commits that main needs, and created a merge conflict between feature-a and feature-b that both modified the same file. Run git log --all --graph --oneline to see the mess. An expected-state.md file describes what the clean repository should look like.

Your Task: Untangle the repo. Move the accidental commit off main onto its own feature branch. Cherry-pick the needed commits from old-feature into main. Resolve the merge conflict between feature-a and feature-b by merging one into the other. The final state should match expected-state.md.

Start with the Graph: Before touching anything, run git log --all --graph --oneline --decorate and draw a diagram of what you see. Understanding the current state is 80% of the solution. Compare your diagram against expected-state.md to identify exactly what needs to move where.

What You'll Learn:

• How git log --all --graph reveals branch structure -- the visual representation shows exactly where branches diverge and which commits are orphaned
• When cherry-pick rescues orphaned commits -- you can extract individual commits from any branch without merging the whole branch
• How to resolve merge conflicts step by step: open the conflicted file, choose the correct code, stage the resolution, complete the merge

Reflection Questions:

1. Which part of the tangle was hardest to understand from the graph? Which was hardest to fix?
2. Did you use the Git Safety Framework (Assess-Plan-Protect-Execute-Verify) or did you jump straight to commands?
3. How would you prevent this kind of branch tangle from happening in a real project?

---

Module 4: GitHub & Remote Workflows

Core Skill: Backing up work and collaborating through the cloud

Lesson 4 taught you how to push projects to GitHub, clone repos, and establish the push-pull workflow. These exercises have you practice the full local-to-remote cycle and diagnose common remote configuration problems.

Exercise 4.1 -- Cloud Safety Net (Build)

The Problem: Open the module-4-github-remote/exercise-4.1-cloud-safety-net/ folder. You'll find a portfolio-project/ with HTML, CSS, and JavaScript files for a personal portfolio site, plus a secrets.json file containing FAKE API tokens that must never be pushed to GitHub. Nothing is under version control yet, and nothing is on GitHub.

Your Task: Initialize the repo, create a .gitignore that protects secrets.json, commit your files, create a GitHub repository, and push. Then verify your backup works: clone the repo to a separate test-clone/ folder, confirm all files are present and secrets.json is absent. Finally, make a change locally, push, pull in the clone, and verify the change appears. This establishes the complete push-verify-pull cycle.

Verification Checklist:

1. secrets.json does NOT appear in git status after adding .gitignore
2. After pushing, GitHub web interface shows all expected files but NOT secrets.json
3. After cloning to test-clone/, ls confirms secrets.json is absent
4. After making a local change and pushing, git pull in the clone retrieves it

What You'll Learn:

• Why .gitignore must be committed before sensitive files are added -- if you add secrets first and .gitignore second, the secrets are already tracked
• How clone-and-verify proves your backup works -- you don't trust a backup you haven't tested
• The push-check-pull rhythm of professional development: make changes, push, verify on GitHub, pull on other machines

Reflection Questions:

1. When you cloned to test-clone/, was secrets.json present? What would have happened if you had committed it before creating .gitignore?
2. Did you check the GitHub web interface to verify your push arrived? What would you do if the push succeeded locally but the files didn't appear on GitHub?
3. How often should you push to GitHub for a solo project? What's the cost of pushing too rarely vs. too frequently?

---

Exercise 4.2 -- Remote Troubles (Debug)

The Problem: Open the module-4-github-remote/exercise-4.2-remote-troubles/ folder. You'll find three sub-scenarios, each with its own setup.sh. Run each setup to create a different remote problem: (A) the local branch is called master but GitHub expects main -- push is rejected, (B) the remote URL points to a repository that doesn't exist -- all remote operations fail, (C) a push is rejected because the remote has commits that your local branch doesn't have.

Your Task: Diagnose and fix each scenario. Scenario A requires renaming the local branch with git branch -m. Scenario B requires updating the remote URL with git remote set-url. Scenario C requires pulling remote changes before pushing. For each scenario, use diagnostic commands before attempting a fix.

Diagnostic Commands for Remote Issues:

• git remote -v -- Shows the URLs your repository is connected to (fetch and push)
• git branch -a -- Shows all branches, both local and remote-tracking
• git status -- Shows whether your branch is ahead of, behind, or diverged from the remote
• git log --oneline origin/main..HEAD -- Shows commits you have that the remote doesn't

What You'll Learn:

• How git branch -m renames branches -- the master to main rename is one of the most common Git operations you'll encounter in existing repositories
• How git remote -v reveals configuration issues -- when remote operations fail, this is always the first diagnostic command to run
• Why pull-before-push prevents rejection -- the remote has the authoritative history, and you must integrate it before adding your own

Reflection Questions:

1. In Scenario A, why would the branch names mismatch in the first place? What default branch name does git init use on your system?
2. In Scenario B, what was the error message when you tried to push to a non-existent URL? Was it clear enough to diagnose without git remote -v?
3. In Scenario C, what happens if you force-push instead of pulling? Why is that dangerous in a team setting?

---

Module 5: Pull Requests & Code Review

Core Skill: Reviewing code professionally with AI transparency

Lesson 5 taught you how pull requests enable code review, discussion, and AI transparency. These exercises have you write real PR descriptions, self-review diffs, and fix PRs that violate professional standards.

Exercise 5.1 -- Transparent PR (Build)

The Problem: Open the module-5-pull-requests/exercise-5.1-transparent-pr/ folder. You'll find a calculator-feature/ repo with a main branch containing calculator.py and test_calculator.py, plus a feature/error-handling branch that adds input validation and error messages. A pr-template.md provides the PR description format your team uses.

Your Task: Write a complete PR description using the template. Self-review the diff between main and feature/error-handling line by line -- annotate what each change does and whether it's correct. Document which parts were AI-generated vs. hand-written (the INSTRUCTIONS.md tells you which). If you find issues during self-review, fix them on the feature branch before finalizing your PR description.

PR Template Sections to Complete:

1. Summary -- What does this PR do and why?
2. Changes -- List of specific modifications with rationale
3. Testing -- How you verified the changes work
4. AI Transparency -- Which parts were AI-generated, what you modified, what you verified
5. Risks -- Anything a reviewer should pay extra attention to

What You'll Learn:

• How PR descriptions serve as documentation for future you -- three months later, the PR description is your only record of why these changes were made
• Why AI transparency builds trust with reviewers -- knowing which parts are AI-generated helps reviewers calibrate their scrutiny
• The self-review habit that catches issues before others do -- reviewing your own diff with fresh eyes is the cheapest quality check available

Reflection Questions:

1. Did self-reviewing the diff reveal any issues you hadn't noticed while coding? What kind of issues?
2. How did you decide what level of detail to include in the AI transparency section? Is there such a thing as too much disclosure?
3. Could a reviewer who has never seen this codebase understand your PR from the description alone?

---

Exercise 5.2 -- PR Cleanup (Debug)

The Problem: Open the module-5-pull-requests/exercise-5.2-pr-cleanup/ folder. You'll find a bad-prs/ folder with three markdown files representing bad PRs: pr-1-no-description.md has the description "Updated code" with 47 files changed and zero context, pr-2-hidden-ai.md contains AI-generated code with no attribution despite the team's transparency policy, and pr-3-failing-checks.md has a good description but the CI checks are failing and the author wants to merge anyway.

Your Task: Rewrite each PR to professional standards. For PR 1, write a proper description explaining what changed and why based on the diff summary provided in the file. For PR 2, add appropriate AI transparency documentation following the team's policy. For PR 3, identify what the failing checks mean and explain what must be fixed before merging. Each rewritten PR should pass your team's review standards.

The Professional Standard: A good PR description lets a reviewer who has never seen the codebase understand: what problem exists, what approach was taken, what was tested, and what risks remain. If a reviewer has to ask "what does this PR do?" -- the description failed.

What You'll Learn:

• What reviewers actually need to evaluate code: context about the problem being solved, the approach taken, testing performed, and any risks or caveats
• How hiding AI usage erodes team trust -- transparency about tools used is a professional norm, not a weakness
• How failing CI tells you what to fix before requesting review -- merge-blocking checks exist to protect the codebase

Reflection Questions:

1. For PR 1, how much context did you need to add before the 47-file change became understandable? Could the author have split this into smaller PRs?
2. For PR 2, where is the line between appropriate AI disclosure and over-documentation?
3. For PR 3, what would happen if the team adopted a culture of merging with failing checks "just this once"?

---

Module 6: Workflow Documentation

Core Skill: Capturing reusable patterns from experience

Lesson 6 taught you how to document Git workflows, create prompt templates, and build reusable patterns. These exercises have you create workflow documentation for a team and audit existing documentation for gaps that caused real incidents.

Exercise 6.1 -- Workflow Builder (Build)

The Problem: Open the module-6-workflow-docs/exercise-6.1-workflow-builder/ folder. You'll find an ecommerce-project/ with a README.md describing a new online store, requirements.md listing the features to build, and team-info.md describing a 4-person team (frontend dev, backend dev, designer, and you as tech lead). The team has never used Git together before.

Your Task: Create a comprehensive git-workflow.md that covers: (1) commit message conventions with examples of good and bad messages, (2) branching strategy (when to create branches, naming conventions, who merges to main), (3) a PR template the team will use for every pull request including an AI transparency section, and (4) a push schedule (how often to push, when to pull, how to handle conflicts). The document should be specific enough that a new team member could follow it on day one without asking questions.

Quality Test: Imagine the designer (who has never used Git) joins the team tomorrow. Could they follow your workflow document to make their first commit, create a branch, and submit a PR? If not, what's missing?

What You'll Learn:

• How workflow documentation eliminates repeated decision-making -- the team makes decisions once and follows the documented pattern
• Why team conventions prevent the chaos of "everyone does it differently" -- four developers with four different commit styles create an unreadable history
• How decision frameworks reduce cognitive load -- instead of debating "should I branch for this?" every time, the documentation answers it

Reflection Questions:

1. Which section of the workflow document was hardest to write? Was it because the decision had multiple valid options?
2. How did you balance specificity (precise rules) with flexibility (room for judgment)? Give an example of each.
3. If the team follows your workflow for a month and discovers a section that doesn't work, what's the process for updating it?

---

Exercise 6.2 -- Pattern Audit (Debug)

The Problem: Open the module-6-workflow-docs/exercise-6.2-pattern-audit/ folder. You'll find a git-workflow.md that a team has been using for 3 months, plus three incident reports: incident-1.md (a developer pushed secrets to main because the workflow didn't mention .gitignore), incident-2.md (two developers merged conflicting branches because the workflow didn't specify merge order), and incident-3.md (a PR was merged without review because the workflow said "reviews are recommended" instead of "reviews are required").

Your Task: Read each incident report, trace the root cause back to a gap or ambiguity in git-workflow.md, and fix the documentation. For each fix, add a "Rationale" comment explaining why the original wording was insufficient and what the new wording prevents.

The Audit Process: For each incident: (1) Read the incident report and identify the developer action that caused the problem, (2) Find the section of git-workflow.md that should have prevented it, (3) Determine whether the section is missing, ambiguous, or uses "recommended" when it should say "required", (4) Write the fix with a rationale comment.

What You'll Learn:

• How to trace incidents back to missing documentation -- the workflow gap is always upstream of the mistake
• Why workflows need regular updating -- documentation written at project start can't anticipate every situation that arises during development
• How gap analysis improves team processes -- each incident reveals a pattern that the documentation should have prevented

Reflection Questions:

1. Which incident could have been prevented with a single sentence added to the workflow? Which required a whole new section?
2. Were the workflow gaps caused by missing information or ambiguous wording? Which is more dangerous?
3. How would you schedule regular workflow audits to catch gaps before they cause incidents?

---

Module 7: Capstone Projects

Choose one (or more). Spend real time on it. This is where everything comes together.

There are no starter prompts -- you design the entire approach yourself. Each capstone requires applying skills from multiple modules to solve a realistic problem. Where module exercises test individual skills, capstones test your ability to orchestrate those skills into a coherent workflow. The quality of your Git practices matters as much as the result -- anyone reviewing your repository should see professional version control habits from the first commit to the last.

The progression across capstones is intentional: Capstone A walks you through the complete Git lifecycle with a project you build yourself. Capstone B applies those skills to building a real professional presence on GitHub. Capstone C puts you in a forensic investigation role, using Git's history tools to reconstruct what happened in a damaged repository. Each capstone demands more judgment and different skills than the last.

Capstone A -- Full Stack Git Journey (Integration)

Take an empty folder through the complete Git lifecycle: initialize a repository with proper .gitignore, build a small project with 8-10 structured commits, create a feature branch to test an AI-generated improvement, merge the successful feature, push to GitHub, create a PR with AI transparency documentation, and write a git-workflow.md capturing your process.

This capstone hits every module: repository setup (Module 1), change tracking and recovery (Module 2), branching (Module 3), GitHub remote workflow (Module 4), pull requests (Module 5), and workflow documentation (Module 6). The project itself can be anything -- a calculator, a todo app, a personal website. What matters is the Git workflow around it.

Estimated time: 2-4 hours.

What You'll Learn:

• How all Git skills compose into a complete professional workflow -- each skill supports the others rather than existing in isolation
• Where to create safety nets in a real project lifecycle -- commits before experiments, branches before risky changes, pushes before major milestones
• How documentation captures your decisions for future reference -- your git-workflow.md becomes a reusable template for every future project

---

Capstone B -- Portfolio Launch (Real-world)

Build a professional GitHub presence from scratch. Create 3 repositories showcasing different skills (choose from: a web project, a data processing tool, an automation script, or a documentation site). For each repository: write a clear README that explains the project, its purpose, and how to run it; configure .gitignore with appropriate patterns for the technology used; create a clean commit history that tells a development story; and push to GitHub with descriptive repository descriptions. Finally, create a profile README (the special repository named after your GitHub username) that introduces you and links to your pinned repositories.

Use the portfolio-templates/ folder for README templates and .gitignore examples.

Estimated time: 2-4 hours.

What You'll Learn:

• How to curate a professional GitHub profile that employers and collaborators actually want to see
• Why clean commit history demonstrates development discipline -- messy commits signal careless habits
• How README quality signals project quality -- a well-documented repository earns trust before anyone reads the code

---

Capstone C -- Git Forensics (Forensics)

Open the capstone-C-git-forensics/ folder and run setup.sh. This creates a "crime scene" repository: secrets were committed and then deleted (but they're still in history), someone force-pushed over a teammate's work (the overwritten commits are in the reflog), there are unresolved merge conflicts in two files, and three abandoned experiment branches contain code that was never reviewed.

Investigate the repository using git log, git reflog, git blame, and git diff. Write a forensic report (FORENSIC-REPORT.md) documenting: what happened (timeline of events reconstructed from Git history), what damage was done (secrets exposed, work lost, conflicts unresolved), and a recovery plan (how to fix each issue, in what order, with what commands).

Estimated time: 2-4 hours.

What You'll Learn:

• How git log, git reflog, and git blame reveal what happened and when -- these are your forensic investigation tools
• Why some Git mistakes are hard to fully reverse -- force-pushed history and committed secrets require different recovery strategies than simple undos
• How forensic skills build debugging intuition -- investigating someone else's mistakes teaches you to recognize patterns that prevent your own

---

What's Next

You've practiced the three core skills -- repository management, problem diagnosis, and professional workflows -- across 15 exercises. These skills compound: every exercise makes Git feel more instinctive, so when AI-generated code breaks your project at midnight, you'll reach for the right recovery command without hesitation. Next in the Chapter Quiz, you'll test your understanding of Git concepts and scenarios. The version control patterns you've built here become your safety net for Chapter 12, where your AI Employee will use these same Git workflows to work autonomously on your projects.