Free / Grades 8-9, with reading support
Git Trail Studio
How can a team combine changes and check the right version?
4 flexible sessions / about 165 minutes including practice / snapshots, branches and careful collaboration
Suggested rhythm: two sessions a week for two weeks. Week 1: snapshots and branches. Week 2: conflicts and a final review. Work on paper, speak or dictate; take longer when useful.
Reading, watching and paper activities are free. Parents and instructors can save a collection; scheduling it for a student requires Plus or Lifetime. No upload is required.
Before you begin
Follow ordered instructions, compare short texts, read arrows with a stated direction and calculate a simple percentage. The earlier release lesson is a review, not a complete Git lesson.
Paper repositories, no accounts or commands. Use invented records only. No terminal, repository access, credentials, real commands or deployments are needed. Never use personal records or passwords. Commit letters and small file tables are teaching shorthand, not real Git identifiers. We model ordinary staged commits and one two-parent merge; other workflows can differ.
Materials
- 4 sheets per learner: Project journal
Print four pages or copy the headings into a notebook.
- 2 sheets per learner: First explanation and final review
Use notebook pages or clean scrap paper; keep both versions.
- 1 per learner: Pencil
Speak, dictate, point or use an accessible writing tool.
- 1 shared, optional: Calculator
Use written arithmetic for the final percentage comparison.
- 1 shared: Browser or printed pages
Read the existing lesson transcripts together; separate worksheet printing is optional.
Choose the support that fits
- More support: place previous, staged and working states in separate labeled boxes. Trace one parent arrow at a time.
- More challenge: invent a second pair of edits that merge as text but violate a shared requirement. Supply the starting files and a check that exposes the problem.
- Access options: dictate, point or explain privately. Color, handwriting, uploading, recording and public performance are not required.
What good evidence looks like
- Distinguish working files, staged content and recorded commits.
- Follow parent relationships and current branch labels.
- Use the base and both edits to explain a conflict.
- Check the combined result against an explicit requirement.
- Keep evidence tied to its version and revise an explanation with a stated limit.
These are discussion criteria, not a new automatic score. Existing lesson and worksheet records keep their own subjects. Checking off a planned task does not demonstrate mastery or add a second grade.
Session 1 / about 40 minutes
Trace the recorded snapshot
Goal: Separate the previous commit, staged snapshot and current working file before and after an ordinary commit.
Preparation / about 8 minutes of adult support: Prepare journal 1 and a first-explanation sheet. Label three boxes; no actual files or commands are needed.
Git records project snapshots in commits. The working file is what you are editing; staging selects content for the next ordinary commit. In our separate example, the previous commit contains MAP. You edit it to DOCK and stage that version, then edit the working file again to SAIL without staging again. The next ordinary commit records DOCK, while the working file still says SAIL. Staging is not a magic vacuum for future edits. The old commit still describes MAP. A local commit does not by itself send work to another computer.
Why can a file have both staged and unstaged changes? Which content should a teammate review before this ordinary commit?
- Ship a small change carefully / about 10 minutes
- Ship a Change Carefully / about 10 minutes
- Trace a staged change / about 20 minutes
Fun fact: A staged file can be edited again before committing. Git can therefore report that the same file has both staged and unstaged changes. Source
S3U / Git Trail Studio / Journal 1 of 4
Three states, not one file label
The recorded note says OPEN. Edit it to READY and stage that content. Then edit the working note to GO without staging again. Make an ordinary commit of the staged content. No automatic staging, push or other action occurs.
| Checkpoint | Content and reason |
|---|---|
| Previous commit, before and after | |
| Staged content just before committing | |
| New commit content | |
| Working content after committing |
What would need to happen before a later ordinary commit could record GO? Is editing or committing alone a remote upload?
Keep a first explanation on another sheet: how can a team tell exactly which content it recorded and checked?
Session 2 / about 40 minutes
Follow branches through history
Goal: Trace parent relationships, shared ancestors and separate branch tips without treating the newest label as every branch.
Preparation / about 8 minutes of adult support: Prepare journal 2. In every diagram arrows point from a child commit toward its parent, not forward in time.
A branch name points to a commit and moves as new commits are made on that branch. Creating a branch name does not copy the whole project into a second physical folder. In our worked graph, A is the starting commit, B has parent A, C has parent B and D has parent B. main points to C; labels points to D. C and D share B, but neither is the other's ancestor. Recording D on labels does not silently move main. Each commit keeps its own parent relationship; the names tell us where those branches currently point.
Which history can be reached by following main backward? Why does a later commit on labels not prove main contains that change?
- Read my branch graph / about 15 minutes
- Explain what the branch did not change / about 10 minutes
- Draw a before-and-after history / about 15 minutes
Fun fact: Two different branch names can point to the same commit. The names alone do not imply two different snapshots. Source
S3U / Git Trail Studio / Journal 2 of 4
Shared past, separate current tips
P is the initial commit. Q has parent P. R has parent Q. S has parent Q. main points to R and draft points to S. Starting on draft with no uncommitted changes, record new commit T whose parent is S. No merge or other branch update occurs.
| Question | My trace and explanation |
|---|---|
| main tip after T is recorded | |
| draft tip after T is recorded | |
| Ancestors reached from T | |
| Most recent shared ancestor of R and T |
Draw the graph with arrows to parents. Is R an ancestor of T? Explain from the links, not the alphabet or a guessed timestamp.
Could another branch name point to T too? Explain why that would not require a different commit or a duplicate folder.
Session 3 / about 40 minutes
Resolve meaning, not just markers
Goal: Compare a common base with both branch edits, resolve a supplied same-line conflict and explain why a clean text merge still needs checks.
Preparation / about 10 minutes of adult support: Prepare journal 3. Use the supplied requirement as the authority for the desired text, not which edit was made last.
A merge combines histories. In this divergent example, main changed a title from PORT to EAST PORT and signs changed the same title to WEST PORT. Git reports a conflict rather than deciding the intended wording. Our team requirement says the final title must name both ports, so it resolves the line as EAST / WEST PORT and checks it. A two-parent merge commit can record that resolution and both histories. Deleting conflict markers without reviewing the content is not a solution. Different-file edits may merge without a text conflict yet still disagree about behavior.
What does the base tell us? Why is the latest timestamp not the requirement? What could go wrong even when a merge reports no text conflict?
- Review both sides of a conflict / about 15 minutes
- Check a clean-looking combination / about 15 minutes
- Explain my merge decision / about 10 minutes
Fun fact: A merge commit can have more than one parent. Our example uses two, allowing both contributing histories to remain reachable. Source
S3U / Git Trail Studio / Journal 3 of 4
A successful merge is not a correctness proof
Case A: base title is CLUB; main changes it to ART CLUB; posters changes it to CODE CLUB. A same-line conflict is reported. The approved exact title is ART AND CODE CLUB. Case B: one branch changes button.txt to open notes.html; the other renames the old page to journal.html. The different files merge without a text conflict. The required button destination is the existing page.
| Review item | My decision and evidence |
|---|---|
| A: resolved title and requirement | |
| A: why neither proposed title is enough | |
| B: combined destination and filename | |
| B: check and repair needed |
For A, preserve the base and both proposals, then show the resolution. What should be checked before recording the two-parent merge?
For B, explain why no text conflict does not prove the button works. Follow the link to the actual supplied filename, not to a hopeful commit message.
Session 4 / about 45 minutes
Demonstrate a careful team handoff
Goal: Review evidence for the exact combined version, distinguish local history from remote sharing and revise the first explanation with a model limit.
Preparation / about 9 minutes of adult support: Bring all journals and the first explanation. Prepare a private spoken or paper review; nobody is monitoring live.
A team should review the combined result, not just the separate branch reports. In this worked record, C and D each passed their chosen checks; the new merge M has not been checked. Those reports do not become an M report by standing nearby. Our stated release rule requires all selected checks to pass on the current version. Also distinguish local from remote: committing changes local history, while sharing it needs a separate successful operation such as a push. A permission or network failure can prevent that sharing. Tests, sharing and deployment are different events.
Which exact version does each report describe? What would establish that a remote received the commit? Can a successful push prove a deployment happened?
- Read release gates and recovery limits / about 10 minutes
- Read a Release Gate / about 10 minutes
- Present and revise my team handoff / about 25 minutes
Fun fact: Git can record commits locally without contacting a remote. That is useful offline, but it is not proof that collaborators have received those commits. Source
S3U / Git Trail Studio / Journal 4 of 4
Evidence belongs to a version
The team merges R and T into M, then makes correction N. Reports: R passed; T passed; M has 9 passes and 1 failure; N has not been tested. The team requires every selected check to pass on the current version. N exists locally; its only push attempt failed. No deployment record is supplied.
| Review item | My calculation or evidence limit |
|---|---|
| M pass percentage and all-pass decision | |
| What the M report proves about N | |
| What is known about sharing N | |
| Checks needed before a release decision |
Privately demonstrate your snapshot trace, branch graph and merge resolution, then review N using only the supplied records. Do not invent successful testing, remote receipt or deployment.
Compare your first explanation with your final one. What changed or stayed sound, and why? State a limit: this project does not cover all Git commands, hosting permissions, history rewriting or deployment systems.
What changed in your explanation?
Show your evidence, explain one revision, and choose a question to investigate next. You can keep everything on paper.
Optional: record actual offline learning in Learning Records. Keep reported minutes separate from website time. For an assigned pack, use your existing daily tasks; this page does not award additional completion credit.