█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Software Engineering/Git and GitHub Pro/Passion Project: Pro GitHub Repo
150 minAdvanced

Passion Project: Pro GitHub Repo

After this lesson, you will be able to: Take an existing project and set up a professional GitHub repository with branch protection, full CI, auto-deploy to Vercel, and contributor docs.

This is the passion project for the Git and GitHub Pro sub-track per Curriculum-Upgrade.md. Pick a project you already own (or one from another LastWrite subtrack) and upgrade its GitHub setup to professional bar.

Prerequisites:Contributing to Open Source

Why this is the passion project

Anyone can push code to GitHub. The candidate who can configure a repo so it enforces good practices automatically stands out instantly. After this project, you'll have a public repo URL on your resume that proves you operate at the level of a working engineer, not just a tutorial-follower.

Milestone 1 — Pick the project

Don't start a new one. The work is the polish, not new features.

  1. 1

    Pick a project you already have on GitHub (the rn-passion-project / aa-cf-passion-project / ai-passion-project all qualify)

  2. 2

    If you don't have one, fork a small public project (anything you actively use)

  3. 3

    Create a checklist of the gaps: missing CI? no PR template? no branch protection? no auto-deploy?

  4. 4

    Estimate 2-4 hours total; this is configuration, not feature work

Milestone 2 — Repo hardening

Apply everything from se-git-04.

  1. 1

    Enable branch protection on main: require PR + 1 approval + status checks + linear history

  2. 2

    Add .github/CODEOWNERS (it can just be yourself for a solo project; the structure shows you know it)

  3. 3

    Add .github/PULL_REQUEST_TEMPLATE.md (from se-fund-05)

  4. 4

    Add .github/ISSUE_TEMPLATE/bug_report.md and feature_request.md

  5. 5

    Add a CONTRIBUTING.md explaining how to set up the project locally + how to submit a PR

  6. 6

    Add a CODE_OF_CONDUCT.md (Contributor Covenant template is fine)

  7. 7

    Add a LICENSE file (MIT is the safe default for personal projects)

Milestone 3 — CI workflow

Apply se-git-05.

  1. 1

    Create .github/workflows/ci.yml with lint, type check, and test jobs

  2. 2

    Enable caching (cache: npm or pnpm) to keep CI fast

  3. 3

    Add matrix builds across Node 18/20/22 if your project supports them

  4. 4

    Make the required status check the merged-ci check; you can require it on the protected branch from Settings > Branches

  5. 5

    Verify by opening a PR with an intentional lint error; confirm CI fails and the merge button is disabled

Milestone 4 — Auto-deploy to Vercel

Apply the deploy YAML from se-git-05.

  1. 1

    Connect the GitHub repo to a Vercel project (vercel.com > Add new > Project)

  2. 2

    Vercel auto-deploys preview URLs for every PR

  3. 3

    Verify the preview URL appears as a GitHub status check on a sample PR

  4. 4

    For backend / non-Next.js projects, write a .github/workflows/deploy.yml that triggers on push to main

  5. 5

    Document the production URL in the README

Milestone 5 — A README that sells the project

Hiring managers read READMEs in 30 seconds; optimize for that.

  1. 1

    Top of file: project name + one-sentence description + a screenshot or gif

  2. 2

    Badges row: CI status, deploy status, license

  3. 3

    'Try it' section: link to the live URL + one-line install instructions

  4. 4

    'Why' section: one paragraph on the problem the project solves

  5. 5

    'Architecture' section: a short diagram or bullet list of the stack

  6. 6

    'Local development' section: clone, install, run, test

  7. 7

    'Contributing' section: link to CONTRIBUTING.md

  8. 8

    'License' section: link to LICENSE

  9. 9

    If the README is more than two screens long, split into multiple .md files (ARCHITECTURE.md, etc.)

💡 How to talk about this in an interview

Open the repo on screen-share. Walk through the README, the CI workflow, the branch protection settings (under Settings > Branches; show the rule), and the Vercel preview URL on a sample PR. Then open one of your own PRs and walk through the description + the CI checks + the reviewer assignment via CODEOWNERS. Three minutes of demo proves you operate at the level of a working engineer.

Common mistakes only candidates with offers avoid

Skipping the README. The most-visited file in any repo; hiring managers read it first. Configuring CI but never running it against a real PR. Untested CI is decorative. Leaving stale `WIP` or `TODO` labels in the project board. Recruiters notice. Choosing fancy badges over a clean README. One row of green badges is fine; ten is clutter. Skipping the LICENSE file. Without one, your code is technically all-rights-reserved and nobody can legally use it.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Contributing to Open Source
Back to Git and GitHub Pro
Git and GitHub Pro Job Readiness→