Case study: a team project from first commit to release

The last Git lunch of the course, on February 22, was a planning session rather than a lesson. Tidewater's two spring deliverables, the third edition of Coastal Day Hikes and TrailCheck 2.0, would both be finished in the repositories the team had set up over the winter, and Priya asked Owen to lead the session using everything the course had covered. The plan below is the one the team agreed on that day for the weeks to April. It brings together commits, branches, pull requests, issues, projects, forks, codespaces, Actions and Pages, and adds the last piece: releases.

Where the team started

Owen began by listing what already existed, so the plan would build on it rather than reinvent it.

Step 1: one issue per piece of work

Every remaining task became an issue before anyone started it, so that the project would show the whole picture. Owen used the correction form for the remaining text fixes, and Priya created issues for the website work: the new search box, the redesigned closures page, trail status colors, and support for version 2 of the trail-report format, which Malik's contributions had shaped. Big items were split into sub-issues. Each issue got labels, an assignee, the right milestone, a Target date and an Iteration in the project. The auto-add workflow from lesson 8 meant every new correction joined the project automatically.

Step 2: a branch and a pull request per issue

Work followed GitHub flow from lesson 3. Each person created a short-lived branch for one issue, named after it, such as 58-closures-redesign, committed in small steps with clear messages, and opened a pull request early, as a draft if it was not ready. Pull request descriptions used Closes #58 so that merging would close the issue and the project workflow would move it to Done. Editors worked in github.dev or the web editor; the web team worked in codespaces from the dev container, so that Lena's environment matched Priya's exactly.

Step 3: review, checks and protection

Every pull request needed the checks from lesson 11 to pass and one approval, and changes to chapters needed an editor code owner. Safety-related text needed Grace herself, through the CODEOWNERS rule from lesson 5. Reviewers used suggested changes for small fixes and the Request changes outcome when something had to be fixed before merging. The team agreed to use squash and merge, so each pull request became one commit on main with its number in the message, which made the history of the release easy to read.

Step 4: tracking progress

Each Monday the Git lunch became a fifteen-minute stand-up around the project board. The team looked at the current iteration, moved anything blocked, and read the insights chart. Grace posted a status update on the project each Friday, marked on track or at risk, which the owners read instead of asking for reports. The 3rd edition milestone in trail-notes showed the corrections on their own.

The plan set a content freeze on Friday, March 19: after that date, only corrections labeled safety or approved by Grace could merge into the guidebook text, so that the proofs sent to the printer would match main.

Step 5: tags and releases

A tag is a name that permanently marks one commit, such as the commit that went to the printer. Unlike a branch, a tag does not move when new commits are made. Git has lightweight tags, which are just names, and annotated tags, which also store a message, the tagger and a date and are recommended for releases. Tags are created with git tag and must be pushed explicitly.

git switch main
git pull
git tag -a v2.0.0-rc.1 -m "Release candidate for TrailCheck 2.0"
git push origin v2.0.0-rc.1

A release on GitHub is built on a tag. It adds a title, release notes written in Markdown, optional files to download, such as the PDF proof of the guidebook, and a flag that can mark it as a pre-release. Releases appear on the repository page and can be watched, so people can be notified only about new releases. GitHub can generate release notes automatically, listing the pull requests merged since the previous release and thanking new contributors, which the maintainer then edits. Releases can also be created by a GitHub Actions workflow when a tag is pushed.

For version numbers the team adopted semantic versioning, a widely used scheme written MAJOR.MINOR.PATCH. The major number goes up for changes that break compatibility, such as version 2 of the trail-report format, which removed an old field. The minor number goes up for new features that keep compatibility, and the patch number for fixes. A suffix such as -rc.1 marks a release candidate. The guidebook used edition names instead, but each printed edition got an annotated tag such as coastal-day-hikes-3rd-edition, so the exact text sent to the printer could always be found.

Step 6: the release checklist

Owen wrote the release day checklist as a task list in a pinned issue, so that each box could be ticked by the person who did it and the issue would record when everything happened.

## Release checklist: TrailCheck 2.0.0
- [ ] All issues in the Spring 2027 milestone closed or moved
- [ ] Checks green on main
- [ ] Release candidate v2.0.0-rc.1 tested on phones and desktop
- [ ] Tag v2.0.0 created from main
- [ ] Release published with generated notes, edited
- [ ] Publish workflow finished; site checked at its address
- [ ] Trail-report format v2 release published in the public repository
- [ ] Announcement posted in Discussions
- [ ] Retrospective booked

Planning for things going wrong

Grace asked what would happen if a mistake was found after release, for example a wrong tide time on TrailCheck the day after 2.0.0 went live. The plan answered with a hotfix: a small branch from main, named for the issue, with one focused commit, an expedited review by Grace and one developer, and a patch release, 2.0.1, as soon as it merged. Because the publish workflow runs on every merge to main, the corrected site would be live within minutes, and the release notes for 2.0.1 would say exactly what changed and why. For the printed book, the team agreed that corrections found after the printer date would go into an errata page on TrailCheck, each one linked to its issue, and into the next printing.

Step 7: after the release

The plan ended with a short retrospective, a meeting to ask what went well and what to change. Owen proposed three questions for it, using data from GitHub rather than memory: the project's historical chart, to see whether work arrived evenly or in a rush before the freeze; the pull request list, to see how long reviews took; and Insights on each repository, to see who contributed. Any improvements would become issues for the autumn guide, which would start from a copy of the project, saved as a template.

Looking ahead to the exam

Owen's GH-900 exam is planned for March 2027. The exam, according to Microsoft's study guide updated in early 2026, has seven areas: Git and GitHub basics (25 to 30 parts in 100), working with repositories (10 to 15), collaboration (10 to 15), modern development practices (10 to 15), project management (5 to 10), privacy, security and administration (10 to 15), and the GitHub community (5 to 10). It is a proctored exam of 100 minutes, scheduled through Pearson VUE, with a passing score of 700, and as a fundamentals-level exam it does not need renewing. This course covered most of the basics, repositories, collaboration, modern development and project management areas. MSBA-161 covers the security, administration and community areas in depth, and MSBA-169 reviews all seven with practice questions. Prices vary by country, so candidates should check the exam page when they schedule.