From good habits to enforced rules
Anyone can be careful on a good day. Professional repos are safe on a bad day - because the rules, not the humans, refuse to let a failing or unreviewed change reach main. Today you turn everything from Sessions 3-5 into machinery: a version tag becomes a downloadable release, a green check becomes a merge gate, a merge to main becomes an automatic deploy. Then you score your repo the way a reviewer would and pin it on your profile.
Tags, releases, and semver 5 min live
A commit hash is precise but meaningless to humans. A tag pins a friendly, permanent name - a version - to one commit. A GitHub Release turns that tag into something people can download, with notes describing what changed. Semantic versioning gives the number itself a meaning so anyone can read risk at a glance.
LiveAnnotated tags and gh release create3 min▶
- An annotated tag is the professional default.
git tag -a v1.0.0 -m "..."stores a message, author, and date - a lightweight tag (git tag v1.0.0) stores only a name. Use annotated for anything you release. - Tags do not push by themselves.
git push origin v1.0.0(or--tags) sends them. Forgetting this is the number one "where is my release?" moment. - A Release is a tag with a face.
gh release create v1.0.0 --generate-notesturns the tag into a GitHub Release page with a changelog built automatically from the PRs merged since the last tag - plus downloadable source archives.
Self-studyWhich number moves? one line each2 min read▶
| Change | Bump | Example |
|---|---|---|
| Breaking - existing use stops working | MAJOR | 1.4.2 → 2.0.0 |
| Feature - new, backward compatible | MINOR | 1.4.2 → 1.5.0 |
| Fix - bug patched, nothing new | PATCH | 1.4.2 → 1.4.3 |
When MAJOR or MINOR bumps, the numbers to its right reset to zero. Auto-generated release notes group the merged PRs so the changelog writes itself - one more reason short, clear PR titles from Session 3 pay off.
Branch protection + CI as a gate 4 min live
Until now the green check from Session 5 was a suggestion - you could merge past a red one if you were reckless. Branch protection turns it into a gate. In Settings → Branches you add a rule for main that requires a PR, requires that CI check to pass, requires one approval, and forbids direct pushes. The habits become law.
LiveThe four rules that make main safe2 min▶
- Require a pull request before merging. No pushing straight to main - every change arrives as a reviewable PR.
- Require status checks to pass. Select your Session 5 CI job - a red run blocks the merge button entirely.
- Require one approval. A second pair of eyes signs off before code lands. Pair with CODEOWNERS to auto-request the right reviewer.
- Require the branch to be up to date. The PR must include the latest main, so checks run against what will actually merge.
This is how a professional repo protects production. A brand-new contributor on their first day literally cannot break main - they can open a PR, but the rules block the merge until CI is green and a maintainer approves. The safety comes from the configuration, not from everyone remembering to be careful. That is the whole point of protection.
Deploy Pages via Actions + the pro-repo bar 4 min live
The non-tech track published a site by hand in Settings. Now you automate it: set the Pages source to GitHub Actions and add a deploy workflow, and every merge to main republishes the site on its own. That closes the loop - reviewed code becomes live product with no manual step. Around it sits the professional-repo bar: the handful of files and rules that make a reviewer trust your work.
Self-studyCommunity-health files that make a repo welcoming2 min read▶
- CONTRIBUTING.md - how to set up, branch, and open a PR here. It answers the first question every new contributor has, once.
- Issue and PR templates -
.github/ISSUE_TEMPLATE/andPULL_REQUEST_TEMPLATE.mdprompt for the details you always end up asking for anyway. - Dependabot - a
.github/dependabot.ymlfile opens automatic PRs to bump vulnerable dependencies, so security upkeep runs itself.
Cut a release ★ 8 min · everyone tags
On your my-project repo, make sure you are on an up-to-date main: git switch main && git pull.
Tag this commit as your first version: git tag -a v1.0.0 -m "First release", then push the tag: git push origin v1.0.0.
Turn the tag into a Release with auto notes: gh release create v1.0.0 --generate-notes. Open the URL it prints and read the changelog built from your merged PRs.
Discuss out loud: if your next change removed a feature people rely on, what version would it be? (Answer: v2.0.0 - a MAJOR bump.)
Protect main ★ 7 min · everyone locks
On GitHub, go to Settings → Branches → Add branch ruleset (or classic Add rule) and target main.
Turn on: Require a pull request before merging, Require status checks to pass (select your Session 5 CI job), and Require 1 approval. Save.
Now try to break the rule: git switch main, make a tiny edit, commit, and git push. Watch GitHub reject it - the push is refused because main now requires a PR.
Sit with that for a second. Feel the safety: from now on, nothing reaches main without a review and a green check. That is a protected branch.
main and the rule is enabled.
The graduation scorecard ★ 6 min · everyone scores
Six sessions in one widget. Tick every row your my-project repo genuinely has and read the verdict - it is the exact list a reviewer runs down before they trust a repo.
Your graduation lap ◐ one real project
- Walk the full stack on one real project. Take something you actually own and give it the works: README + license → CI on every PR → protected main → a tagged release. Every row on the scorecard, for real.
- Write a CONTRIBUTING.md so the next person (or future you) knows how to set up, branch, and open a PR.
- Pin the repo on your profile. It is now proof you run a repo the professional way - link it from your LinkedIn.
- Where this goes next: the non-tech track teased this one; a future AI-literacy course covers Copilot + AI pair-programming; a security course covers CodeQL, secret scanning, and supply-chain safety. Star this course's repo so you catch them.
Three questions before you graduate 🎯 ◐ 90 seconds
1 · Your change removes a feature other people depend on. Which part of the semver number bumps?
MAJOR means "existing users must adapt". Removing something they rely on breaks them, so 1.x becomes 2.0.0. MINOR is for backward-compatible features; PATCH is bug-fix-only.
2 · With branch protection requiring a PR, an approval, and a passing check, what can no longer happen?
Protection blocks direct pushes and holds the merge button until the checks pass and a reviewer approves. Merging still happens - only unsafe merges are stopped.
3 · What does cutting a Release add over a plain git tag?
A tag is just a name on a commit. gh release create --generate-notes turns it into a GitHub Release page with an auto-built changelog and downloadable source archives.
Coverage - the whole track, and what is deliberately next
Session 6 closes the tech track. Here is what today covered, what is self-study, and what is left for future courses on purpose.
Session 6 cheat sheet · pin this
git tag -a v1.0.0 -m "..." then git push origin v1.0.0. Tags do not auto-push.gh release create v1.0.0 --generate-notes - notes + downloads from your merged PRs.