Module 3: Git Fundamentals: Case Studies
These cases focus on using Git as a collaboration and recovery tool, not just a place to save snapshots.
Case Study 1: The Commit That Changes Everything
Scenario: A learner commits formatting, feature code, dependency changes, and generated files together. Reviewers cannot tell what matters.
Source anchor: Pro Git: Recording Changes to the Repository.
Module concepts:
- staging
- atomic commits
- diffs
- reviewability
Wrong Approach
Commit every modified file because the project currently works.
Better Approach
Inspect the diff, stage related hunks, write a commit message that explains one intent, and leave unrelated changes for another commit.
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| One large commit | Fast snapshot | Hard review and rollback |
| Atomic commits | Clear history | Requires staging discipline |
| Too many tiny commits | Fine trace | Can fragment context |
Failure Mode
A bug fix must be reverted, but the commit also contains unrelated setup work.
Required Artifact
Produce a commit plan listing files, reason for inclusion, excluded files, and final commit message.
Project / Capstone Connection
Use the same commit-plan standard in later semester projects so your history reads like a sequence of reviewable engineering decisions.
Case Study 2: Rebase on Shared History
Scenario: A learner rebases a branch that teammates already pulled, then force-pushes. Other branches now have confusing duplicate commits.
Source anchor: Pro Git: Rebasing.
Module concepts:
- merge vs rebase
- shared history
- force push risk
- recovery communication
Wrong Approach
Use rebase everywhere because the graph looks cleaner.
Better Approach
Rebase private local work when useful; merge or coordinate carefully for shared branches. If rewriting is unavoidable, communicate, use safer force-with-lease behavior, and help teammates recover.
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| Merge | Preserves shared history | Can create extra merge commits |
| Rebase private work | Linear local story | Rewrites commit IDs |
| Rebase shared work | Clean graph | Disrupts collaborators |
Failure Mode
Two developers unknowingly continue from different versions of the same branch history.
Required Artifact
Write a branch-history decision note: branch owner, shared status, chosen integration method, and recovery plan.
Project / Capstone Connection
Bring this note into collaborative project work later in the roadmap, especially when merges, rebases, or release branches affect more than one contributor.
Case Study 3: Lost Work Recovery
Scenario: A learner resets a branch and thinks their work is gone. They do not know how to inspect reflog, stash, or previous commits.
Source anchor: Pro Git: Recording Changes to the Repository.
Module concepts:
- working tree vs index vs repository
- reflog awareness
- stash
- recovery workflow
Wrong Approach
Panic, make more random commands, and overwrite additional state.
Better Approach
Stop changing files, identify where the work last existed, inspect status/log/reflog, and recover to a new branch before cleaning up.
Tradeoff Table
| Choice | Gain | Cost |
|---|---|---|
| Random recovery | Might stumble into fix | Can lose more context |
| Calm inspection | Preserves evidence | Requires Git model |
| New recovery branch | Safe experimentation | Extra cleanup |
Failure Mode
The learner destroys recoverable work by stacking commands without understanding state.
Required Artifact
Create a Git incident runbook with "stop", inspect commands, recovery branch step, and confirmation checklist.
Project / Capstone Connection
Treat this runbook as the first operational recovery artifact in your portfolio; later incident notes should show the same calm inspection flow.
Source Map
| Source | Use it for |
|---|---|
| Pro Git: Recording Changes | Working tree, staging, commit workflow. |
| Pro Git: Rebasing | Merge/rebase tradeoffs and history rewriting. |