Git & Professional Version Control Build a correct mental model of working tree, staging, commits, diffs, identity, repository hygiene, and safe engineering history.
Book 4 · Version control Course baseline: September 17, 2026 · Windows-first · Project-driven · Production-oriented
Contents 1. Git mental model 7. .gitignore
Phase 01 | Page 2 of 5
Git is the memory of the engineering process Git is not merely a cloud backup mechanism. It records intentional snapshots of a project's state so developers can compare, review, branch, integrate, and recover changes.
Figure 1 - Git mental model - The staging area lets you decide exactly what belongs in a commit instead of committing every modified file by accident.
The official Git install page lists Git 2.55.0(5) as the maintained Windows build as of the Phase 01 baseline. WinGet is supported:
winget install --id Git.Git -e --source winget
git --version
Get-Command gitPhase 01 | Page 3 of 5
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global --listYour Git identity becomes metadata on commits. It is not the same thing as logging in to GitHub.
Set-Location "$HOME\Developer\full-stack-2026-lab"
git init
git status
"Phase 01 Git practice" | Set-Content README.md
git statusgit add README.md
git status
git commit -m "docs: add Phase 01 practice readme"
git log --oneline --decorate -5Professional habit: read git status before and after every important Git action.
git diff
git diff --staged
git show HEADgit diff What changed in the working tree but is not staged?git diff --staged What exactly will the next commit contain?git show HEAD What did the latest commit record?Phase 01 | Page 4 of 5
.gitignore is part of architecture hygiene
Generated output, dependencies, logs, editor state, and secrets should not pollute version history. Later we will ignore node_modules , .env , build artifacts, and other generated files.
A good commit is a coherent engineering statement. Avoid a week of unrelated changes under update stuff . Prefer messages such as feat: add health endpoint , fix: validate missing task title , or docs: document local setup .
Make one coherent change → Review diff → Stage intentionally →
Commit with useful message → Continue
A branch is a movable name pointing at a commit. We will use branches more seriously when collaboration and CI/CD arrive. For now, understand that branches isolate lines of work without duplicating the entire project manually.
• Do not commit .env secrets. • Do not delete .git because a command feels confusing. • Do not run destructive reset/clean commands copied from the internet before understanding what they remove. • Do not use GitHub Desktop or an IDE as a substitute for understanding Git state.
□ git --version works. □ Name, email, and default branch are configured. □ You can explain working tree, staging area, commit, and remote. □ You can create a repository, stage one file, commit, inspect log, and inspect diffs.
Phase 01 · Book 4 · Version control
Phase 01 | Page 5 of 5
Git and Professional Version Control matters because it changes a real boundary in TaskFlow. The goal is to understand the inputs, owner, observable output, and failure modes before adding more abstraction.
Restate the goal of “Git and Professional Version Control” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: source file → tool/runtime → process → OS environment → terminal evidence. Mark the one boundary this lesson changes.
Inspect the current repository state and record the exact files, route, table, or runtime involved. Avoid creating an abstraction before you can name the existing owner.
Implement the smallest vertical slice. Add one coherent change, run the narrowest verification command, and read the output before continuing.
Connect the slice to TaskFlow’s phase artifact: A verified toolchain report showing shell, Git, Node, Corepack/pnpm, editor, PATH, ports, and diagnostic commands.. Verify behavior from the outside as a user or API client would.
Create one controlled failure that is safe to reproduce. Predict the symptom first, capture evidence, locate the earliest broken boundary, then fix only that cause.
Close the reference and rebuild or explain the core change from memory. Record what you would monitor or test before trusting the same change in production.
Input -> owner -> transformation -> observable output -> failure evidenceDo not copy this as a finished answer. Predict what each boundary does, type the smallest useful slice, run it, then compare the result with your prediction.
Return to the nearest observable boundary: input, network, process log, database, or rendered UI. Compare actual evidence with the predicted path.
Change one variable at a time and reproduce the original failure after the fix; otherwise you have correlation, not diagnosis.
Without copying the final source, create a second small scenario that applies “Git and Professional Version Control” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Enable Corepack and activate the repository package-manager version.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Port already in use by a forgotten development process
Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.Why does this responsibility live here, what input does it trust, what output proves success, and what would go wrong if another layer owned it?
If your explanation is vague, repeat the boundary trace before moving on.Close the reference. Reproduce the core idea from memory or explain the exact request/data flow aloud. Then check your diff or notes for accidental shortcuts that bypass validation, authorization, error handling, or verification earned in earlier phases.