GitHub-Specific Workflows

The plain-language idea

Everything up to this lesson has been git itself — the tool works identically whether your remote is GitHub, GitLab, a coworker's laptop, or a USB stick. This lesson is different: it's about mechanics that only exist because GitHub chose to build them on top of git's plumbing. Move to a different host and none of this transfers as-is, even though the underlying repo does.

The core pieces fit together as a gate: branch protection rules on a repo (Settings → Branches) say a branch like main can't be pushed to directly and can't be merged into until certain conditions hold. Required status checks are one of those conditions — a rule that says "this PR can't merge until these named checks report success," and those checks are usually jobs from a CI workflow (this platform has a whole separate track on the CI/CD side of that pipeline — the check itself is just a job reporting pass/fail back to GitHub's PR API). CODEOWNERS is another condition: a file that maps paths to required reviewers, so a PR touching lib/ai/** can require sign-off from whoever owns that area before it's mergeable, automatically, without a human remembering to tag them.

See it in a real thing: what actually gates a merge

A CODEOWNERS file at the repo root:

# .github/CODEOWNERS
lib/ai/**        @adesh @ai-team
app/api/**       @adesh
*.md             @docs-team

Any PR touching lib/ai/provider/resolveKey.ts now automatically requests review from @adesh and @ai-team — GitHub reads this file on every PR and adds reviewers itself.

A GitHub Actions workflow triggered by the events that actually matter here:

on:
  push:
    branches: [main]
  pull_request:

Every git push to a PR branch, and every direct push to main, fires this workflow — that's what turns a plain CI script into something GitHub can gate on. Once that workflow's verify job exists, the branch protection UI lets you require it by name:

Settings → Branches → main → Require status checks to pass → verify

Now a PR literally cannot be merged — the "Merge" button is disabled — until that job goes green, no matter who approves it. Combine that with "Require review from Code Owners" and "Require branches to be up to date before merging," and you've encoded "no broken code and no unreviewed code reaches main" as a rule the platform enforces, not a norm people remember to follow.

What people usually miss

Watch out

• Branch protection is repo configuration, not something in the git history at all. It's not a file you can git clone and read — it lives in GitHub's database for that repo, which is why it doesn't travel with a fork or a mirror the way .gitattributes or a CODEOWNERS file does.
• "Require branches to be up to date before merging" changes what a passing check actually means. Without it, a check can pass on a PR branch that's since diverged from main, and the merge itself is never re-verified against the current main — you can merge code that was never actually tested against what it's landing on.
• A repo admin can bypass protection rules by default. "Protected" doesn't mean "unbypassable" unless the rule explicitly includes admins — a common audit finding is a branch that's protected for everyone except the person most likely to fat-finger a direct push.

The genealogy: policy layered on top of plumbing

Git gives you the primitives — commits, branches, the ability for a server to accept or reject a push. GitHub's contribution here is a policy layer bolted on top: turning "a CI job reported success" and "a designated reviewer approved" into conditions a merge button actually respects, the same way a linter enforces a style guide that plain JavaScript syntax never required.