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.3 KiB
Branching and Merging
Why branches exist
Without branches, every commit happens on the same single line of history — risky work and finished work are indistinguishable, and two people can't develop different things simultaneously without directly interfering with each other. A branch is a movable pointer to a commit, letting you develop something in isolation and only combine it back into the main line when it's actually ready.
Creating and switching branches
$ git branch feature-login # create a new branch (doesn't switch to it)
$ git checkout feature-login # switch to it
$ git switch feature-login # the newer, clearer equivalent of checkout for this purpose
$ git checkout -b feature-login # create AND switch in one step
Commits made while on feature-login only affect that branch — main is completely unaffected
until you deliberately combine them.
Merging: combining two branches' history
$ git checkout main
$ git merge feature-login
Git attempts to combine the two branches' history automatically. When the two branches changed DIFFERENT parts of a project, this usually succeeds with no fuss.
Divergence and conflicts
When both branches changed the SAME lines of the SAME file differently, Git can't automatically decide which version is correct — this is a merge conflict. Git marks the conflicting section directly in the file:
<<<<<<< HEAD
your current branch's version
=======
the incoming branch's version
>>>>>>> feature-login
A conflict is not an error you did something wrong — it's Git correctly refusing to silently guess which change you actually want. You resolve it by editing the file to the content you actually want (removing the markers), then staging and committing to complete the merge.
Instructor Notes
Lesson goal: Frame merge conflicts as an EXPECTED, normal part of collaborative work — not a sign of failure — before students hit their first real one in this module's Lab.
Approximate timing: 15 minutes read; 10 minutes live.
Common misconception to watch for: panicking at the sight of conflict markers — reinforce explicitly that this is Git behaving correctly, not breaking.
Demo idea: deliberately narrate a conflict as "Git is asking YOU to make a decision it can't make safely on its own" rather than "something went wrong."