Level 6 — Real-world simulation: one sprint at Northwind Trails

Objective

Everything so far has practised one thing at a time. This lab is a sprint: two pieces of planned work, one urgent interruption, one conflict, and a release at the end. You play the whole team, which is artificial, and the sequence is exactly what a real week looks like.

Set aside ninety minutes. It is worth doing in one sitting, because the point is the shape of the whole thing.

Starting state

• Your own project with the playground pushed, from Lab 2, and main protected (lesson 9.5 or lesson 10.5).
• A pipeline that runs on merge requests: the playground ships one.
• A second clone, playing your colleague Ben, as in Lab 4.
• The better conflict markers on: git config --global merge.conflictstyle zdiff3.

Day 1: plan

1. File two issues, properly (lesson 13.9):
   • #31 "Installation guide is missing the Windows steps" — say where, and what a Windows user should see.
   • #32 "FAQ licence answer is ambiguous" — quote the current sentence and say what is unclear.
2. Label them documentation, and put both in a milestone called v1.3.0.
3. Assign #31 to yourself. Leave #32 unassigned; Ben will take it.
4. From issue #31, create a branch through the platform, then fetch and switch to it locally.

Day 2: the feature branch

5. Update first, then confirm you branched from current main:

   $ git switch main && git pull
   $ git switch docs/31-windows-install-steps

   Copy

6. Write the change in docs/getting-started.md: a Windows section with two or three real steps.

7. Commit deliberately. Read the diff, stage, read the staged diff, commit:

   $ git add docs/getting-started.md
   $ git diff --staged
   $ git commit -m "docs: add Windows steps to installation guide (#31)"

   Copy

8. Break the pipeline on purpose: add a heading that skips a level, for example #### directly under ##. Commit that too, as a separate commit.

9. Push and open a draft merge request with what, why, how to check, and Closes #31.

Day 2, later: the red pipeline

10. Read the failure properly (lesson 14.3): open the failing job, go to the end of its log, and find the line naming the file, the line number and the rule.
11. Fix it and push. Watch the pipeline go green.

12. Tidy the branch before review, since nobody else has it:

    $ git rebase -i main

    Copy

    Mark the fix commit fixup so it merges into the first, leaving one clean commit. Then:

    $ git push --force-with-lease

    Copy

13. Mark it ready and request a review.

Day 3: the review

14. In the second clone, as Ben: check out your branch, read the change, and leave one batched review with a suggestion for a wording change and one question (lesson 13.7).
15. As yourself: apply the suggestion, answer the question in the thread, and resolve it.
16. Do not merge yet. Leave it approved and waiting.

Day 3, meanwhile: the conflict

17. As Ben, take issue #32: branch from main, rewrite the licence answer in docs/faq.md, commit, push, and merge that merge request into main.
18. As yourself, on your branch, rewrite the same sentence differently, commit, and push.

19. Update your branch from main. The conflict appears:

    $ git fetch
    $ git rebase origin/main

    Copy

20. Resolve it properly: read all three versions, and write a sentence that says what both of you meant (lesson 11.3). Then:

    $ git add docs/faq.md
    $ git rebase --continue
    $ git push --force-with-lease

    Copy

21. Merge your merge request, with squash and delete-source-branch, and confirm issue #31 closed itself.

Day 4: the interruption

22. Tag what is on main as the released version, and push the tag:

    $ git switch main && git pull
    $ git tag -a v1.2.0 -m "Release 1.2.0"
    $ git push origin v1.2.0

    Copy

23. Add two ordinary commits to main, playing the rest of the team continuing to work.

24. A bug is reported in production. Branch from the tag, not from main (lesson 13.2):

    $ git switch -c hotfix/33-wrong-region-name v1.2.0

    Copy

25. Make the one-line fix, commit, push, and open a merge request onto a release/1.2 branch cut from the same tag.

26. Get the same fix onto main as well, by cherry-pick with -x or a second merge request. Confirm with git log --oneline main | head -3 that it is there.
27. Tag v1.2.1 on the release branch and push it.

Day 5: the release

28. Work out what shipped:

    $ git fetch --tags
    $ git log --oneline v1.2.0..main

    Copy

29. Write the changelog entry for v1.3.0 in CHANGELOG.md, with Added and Fixed sections, in the user's words (lesson 13.6).

30. Decide the version number from those entries, and say why in one sentence.
31. Tag and release: create the tag, push it, and create the release page with your notes and the milestone attached.

32. Clean up:

    $ git switch main && git pull
    $ git fetch --prune
    $ git branch -d docs/31-windows-install-steps

    Copy

Expected result

• Two issues closed by their merge requests, and one hotfix issue closed separately.
• main containing one clean commit per piece of work.
• A release/1.2 branch with the hotfix, and tags v1.2.0, v1.2.1 and v1.3.0.
• A release page whose notes a user could act on.
• A local repository with no stale branches, and nothing uncommitted.

If something goes wrong

What you learned

The individual commands were all in earlier labs. What this one adds is the order, and three things that only appear when the work is realistic:

• The pipeline fails at an inconvenient moment, and reading the log properly is faster than guessing.
• Someone else changes the same sentence, and the resolution is usually neither version.
• The urgent thing arrives mid-sprint, and where the hotfix branches from is the only decision that matters.

If you can run this lab unaided, you can work on a real team's repository without anyone needing to explain the process to you.

Next

The reference section is what you use from here: the decision guides when you are unsure, the cheat sheets while the commands are new, troubleshooting when something breaks, and the checklists at the moments that repeat.