The Big Picture: Why Customize SharePoint from a GitHub Repo

Lesson 1: The Big Picture — Why Customize SharePoint from a GitHub Repo

There was a time when "customizing SharePoint" meant deploying farm solutions (.wsp packages) that ran server-side, needed full-trust access, and could take a farm down. That era is over. Modern SharePoint Online customization is client-side code: TypeScript/JavaScript packages that run in the browser, are versioned in git, and are delivered through an app-catalog pipeline you control. If the code isn't in a repo and deployable by a machine, it isn't really "yours" — it's a manual process someone will eventually get wrong.

The mental model: a GitHub repo is the single source of truth for everything you build on SharePoint. A CI/CD pipeline (GitHub Actions) turns that source into a package, pushes it to SharePoint's app catalog, and installs it on sites. Review, rollback, repeat — same muscle memory as shipping any other software.
GitHub repo SPFx source code push GitHub Actions build + package (.sppkg) deploy App catalog add + deploy + install available Sites web parts, extensions

What you can customize (and what you shouldn't)

Modern customization splits into two lanes, and knowing which is which saves you from building the wrong thing:

LaneToolsWhat it changes
Code — reusable UI & behaviorSharePoint Framework (SPFx)Web parts you drop onto pages, and extensions: banners/scripts across a site, custom list columns, list toolbar buttons.
Configuration — sites & structureCLI for Microsoft 365, PnP PowerShell, site scriptsCreating sites, lists, content types, navigation, permissions — "infrastructure as code" for SharePoint.

Most real projects do both: SPFx for the components people see, plus a provisioning script that creates the lists those components read from. This course centers on the code lane (SPFx), then shows you the deployment machinery — including the provisioning tools — that makes it all reproducible from GitHub.

What to avoid: editing pages by hand and hoping, "customizing" via embedded script editor web parts in production, and any recipe that tells you to modify files on a server. None of it survives the next change, and none of it can be reviewed in a pull request.

Why a repo (and not the browser)

Putting customizations in GitHub buys you the same guarantees as any codebase: code review before change, an audit trail, a rollback point, and an environment story (dev catalog → production catalog) that's impossible when someone pastes markup into a page. You also get free documentation: the repo is the living spec of what your SharePoint looks like.

🧠 Knowledge Check

1. What does the modern SharePoint customization model run on?

2. Which of these is the "configuration" lane of SharePoint customization?

3. What is the primary benefit of keeping SharePoint customizations in a GitHub repo?

Further Reading