After this lesson, you will be able to: Configure protected branches, required reviews, status checks, CODEOWNERS, and GitHub Projects so your repo enforces the workflows you actually want.
GitHub's defaults are designed for a single-developer hobby project. Turning a repo into a team-grade artifact takes 30 minutes of configuration and saves hundreds of hours over the project's life.
Settings > Branches > Add rule for `main` (and any other release branch). Enable: Require pull request before merging. Require approvals (1 or 2). Require status checks to pass (your CI). Require branches to be up to date before merging. Require linear history (if you use squash or rebase merge). Restrict who can push (no one, force-push goes through PRs only). These rules are enforced server-side, so even an admin's mistake can't ship broken code straight to main.
Place this in `.github/CODEOWNERS`. GitHub auto-requests review from owners when their files change.
# Catch-all: any change requests review from @platform-team* @your-org/platform-team# Frontend-specificsrc/app/ @your-org/frontend-team*.tsx @your-org/frontend-team# Database migrations require an extra reviewerprisma/migrations/ @your-org/db-leads# Specific files always require security review.github/workflows/ @your-org/security-teamsrc/lib/auth/ @your-org/security-team# A specific person owns this critical filesrc/lib/billing.ts @alice# Order matters: later patterns override earlier.# CODEOWNERS becomes 'required reviewer' if you enable the branch-protection toggle.
A status check is a GitHub Action (or other CI) that reports pass/fail per commit. Branch protection can require specific checks to pass before merge. Typical required checks: lint, unit tests, type check, build success. Optional checks (nice to have but not blocking): performance budgets, bundle size, visual regression. Required checks should run fast (under 5 min total); optional checks can be slow.
GitHub Projects (the new 'Projects v2') is a Notion-like board built on top of Issues and PRs. Free for unlimited contributors on public repos; included for orgs on paid plans. Common views: Kanban board (Todo / In Progress / Review / Done), Table view (filter by milestone), Roadmap (timeline). Custom fields: priority, estimate, sprint, owner. Each Issue + PR auto-syncs status from its state. For most small/medium teams, this replaces Jira-equivalent tooling.
Pick any repo you own. Apply this exact sequence.
Settings > Branches > Add rule for main. Require PR + 1 approval + status checks + linear history. Save.
Add .github/CODEOWNERS (use the example above, simplified for your team).
Add .github/PULL_REQUEST_TEMPLATE.md (from se-fund-05 lesson).
Add .github/ISSUE_TEMPLATE/bug_report.md and feature_request.md (GitHub gives you starter templates from the Issues settings).
Create a Project: Projects > New project > pick the Kanban template. Add fields: Priority (Low/Med/High), Estimate (XS/S/M/L), Sprint (2-week tags).
Wire the repo's Issues into the project automatically: Project settings > Manage access > Repositories > add.
Verify: open a PR from a fresh branch; the template fills in, the CODEOWNERS reviewers are requested, the status checks gate the merge.
Branch protection that allows admins to bypass. Disable that toggle; if a senior engineer needs to bypass, they should know they're doing it (use --no-verify locally, not server admin override). CODEOWNERS without follow-through. If the owners can't review fast, PRs stall. Set up alerting for stale reviews. Status checks that nobody trusts because they flake. Fix flakes immediately; flaky tests teach the team to ignore CI. Project boards that fall out of date. Make it a habit to drag cards live during standup so the board reflects reality.
Pick the strongest single rule.
Sign in and purchase access to unlock this lesson.