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]>
63 lines
2.3 KiB
Markdown
63 lines
2.3 KiB
Markdown
# 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."
|