ced4568andClaude Sonnet 5
e68b6f445a
Adds all 6 ROOT 03 modules (why version control exists, the Git mental model, everyday Git, branching & merging, remote repositories, engineering Git workflow) — 31 activities. Uses only real LOCAL Git repositories throughout — no Gitea account, no network access, and no RootNode-canonical-repo credential is ever needed or exposed in a student Lab (docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md §4). Modules 1, 2, and 6 are conceptual bookends with no lab, matching the flexible readiness standard already used in ROOT 01/02. Adds 3 new hands-on Git scenarios plus 2 MCQs: git-everyday-basics (init/add/commit, validated by inspecting real `git log`/`git show` state, not just command output strings — Step 6's explicit requirement), git-branching-and-merge (a REAL merge conflict caused on purpose by two branches editing the same line, resolved by the student, validated by confirming the conflict markers are gone and a real two-parent merge commit exists), and git-remote-clone-push (a real local bare repository standing in for a remote — clone/commit/push validated by inspecting the REMOTE side directly, not just the student's own clone). All tested end-to-end via the real scenario-validation API, including negative tests. Wires rootnode-git-fundamentals-assessment (2 required + 3 random-draw scenarios) using the existing Phase 3B assessment engine. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2.8 KiB
Engineering Git Workflow
Small commits, meaningful messages
A commit containing "fixed stuff" and 40 unrelated file changes is nearly useless to anyone
reading history later — including future-you. A commit that does ONE logical thing, with a
message describing what and why, is what actually makes git log a useful tool rather than
noise. This isn't pedantry — it's what makes rollback (below) and code review actually
practical.
main as a protected source of truth
Real engineering teams treat their main branch as the one everyone trusts to be in a working
state at all times — direct, unreviewed pushes to main are typically restricted specifically
BECAUSE it's the shared source of truth every deployment and every other branch is built from.
Feature branches (Module 4) exist precisely so risky, in-progress work never threatens that
trust.
Review: another set of eyes before history is permanent
Before a change reaches main, most real teams have someone else look at it first (a "pull
request" or "merge request," depending on the platform). This isn't about distrust — it's a
second perspective catching mistakes, and a natural point to discuss WHY a change is being made,
not just what it does.
History and rollback as safety nets
Because every commit is permanent and inspectable, a bad change can be identified precisely (via
git log) and reverted deliberately — confident recovery, not panic, when something goes wrong.
This is Module 1's original promise, now fully realized: reproducibility and rollback aren't
theoretical, they're what your daily small-commit discipline actually buys you.
Why this matters to DevOps, GitOps, and Infrastructure as Code
Everything in this lesson — small deliberate changes, a trusted source of truth, review before merge, reliable history — is EXACTLY what CI/CD pipelines automate, what GitOps treats a Git repository as authoritative for, and what Infrastructure as Code relies on to safely manage real infrastructure through the same discipline you just practiced on plain text files. ROOT 11 builds directly on this course's habits, not a new set of ideas.
Instructor Notes
Lesson goal: Close ROOT 03 by explicitly naming the professional discipline (not just Git commands) this course was building, and its direct connection to DevOps/GitOps/IaC.
Approximate timing: 15 minutes read; 10 minutes live.
Common misconception to watch for: treating "review" and "protecting main" as bureaucratic overhead rather than genuine risk management — connect it back to the real cost of a bad change reaching a shared source of truth unreviewed.
Discussion question: "Why might a team enforce small commits and review even when working alone on a personal project?" (Good answers: future-you benefits from the same clarity; building the habit now pays off the moment you DO work with others.)