Skip to content

The GitHub Copilot course

This is a hands-on course, not a reference. You’ll spend it inside VS Code with GitHub Copilot, doing one real piece of work end to end: adding an approval workflow to an order-management service - a feature that turns out to need a change to a shared library a dozen other services depend on before you can build it at all. Every lesson takes a problem you’ll really hit (the agent rewrites code in a style your team rejects, a “small” change ripples across twelve consumers, you need work to keep moving while you’re in a meeting) and shows the exact Copilot move that fixes it.

This course is IDE-first. The first-class surface is VS Code + GitHub Copilot - the setup most enterprise engineers are actually allowed to run. JetBrains gets a parity chapter near the end; the Copilot CLI is a footnote, not the spine. If your shop has standardized on Copilot, this is the course written for your constraints.

If you want the spec-level “what is this primitive” view, that’s Foundations. This course is the other half: the muscle memory. And if you’ve done the Claude Code or Codex course, you’ll find a bridge waiting in the Rules chapter - the AGENTS.md you wrote there is read natively here.

  • VS Code installed (latest stable)
  • GitHub Copilot subscription (Individual, Business, or Enterprise)
  • A GitHub account with permission to clone and create branches in two repositories, or one repository with two services/packages you can use as substitutes
  • Basic TypeScript/JavaScript familiarity
  • Git fundamentals (clone, branch, commit, diff)
  • Estimated time: 3-4 hours for the full course

The course uses shared-lib, orders-service, and twelve downstream consumers as a running scenario; those repositories are not bundled with this site. Use equivalent repositories from your team, or follow the substitutions below if you are learning without an inherited codebase:

  • Use any small TypeScript/JavaScript service as orders-service.
  • Use a local package or second repository as shared-lib; a monorepo with two packages works too.
  • For the consumer exercise, use however many packages or services you have and ask the coordinator to report the actual count. A single repository can be used as a dry run.
  • For the MCP chapter, use a server you are authorized to access. If you do not have one, skip the live connection and use a checked-in consumers.json file as the registry response; the trust and scoping decisions still apply.

The examples are intentionally small enough to adapt. Do not paste internal URLs, credentials, or proprietary source into a public issue or MCP configuration.

Twelve chapters, in reading order. Each carries the same two-repo project one stretch further - start at the top, or pick the problem in front of you.

Each chapter carries one running project - two repos, shared-lib and orders-service, that you’ve just inherited on a new team - and the lessons build on each other: each one picks up a problem the last one left you with, adds a move to your repertoire, and hands off to the next.

shared-lib ──────────────▶ 12 consumers
(threshold check + audit helpers live here)
│ one of those 12 consumers
orders-service ◀────────── the approval workflow you're building

The shape of the project is the shape of the course: a change that looks local to orders-service turns out to need a change in shared-lib first - and a shared library change is a different kind of careful than an app change.

So you get the most out of a chapter by reading it in order. But each lesson still stands on its own if you drop in from a search with one specific problem in front of you - you’ll just miss the running story.

What you won’t find is a fixed template stamped onto every lesson. Some need a long worked transcript, some a single setting and a warning, some a digression into why Copilot behaves the way it does. The shape follows the content, the way a good book varies its chapters.