wikis / GitHub / wiki / syntheses / ci-cd-pipeline.md view as markdown report a mistake

End-to-End: From Commit to Deploy

How GitHub's features compose into one shipping pipeline — the path most teams actually run.

1. Branch and commit

Create a feature branch off the protected default branch (repositories-and-git), commit, and push. Signed commits earn a Verified badge (authentication).

2. Open a pull request

The PR is the review and gate point (pull-requests). Keep it small and link the issue (Closes #N) for traceability to Projects.

3. Automated checks run

Opening/updating the PR triggers Actions workflows (on: pull_request): lint, test, build, and code scanning (code-security). Jobs run on runners with a least-privilege GITHUB_TOKEN.

4. Review gate

Branch protection / rulesets hold the merge until: required approvals (incl. CODEOWNERS), all required status checks green, branch up to date, and Dependabot/secret-scanning clean. This is where quality is enforced, not by convention.

5. Merge

Squash/merge/rebase per repo policy. The merge to the default branch is itself an event.

6. Deploy

A on: push (to main) or on: release workflow builds and deploys. Use environments for protection rules (required reviewers, wait timers) and scoped secrets, and prefer OIDC over stored cloud credentials (actions-runners). Targets might be Pages (static), Packages/ghcr.io (images), or external clouds.

The compounding effect

Each layer is optional alone but compounding together: PRs catch logic errors, required checks catch regressions, code scanning catches vulns, environments gate prod, and OIDC removes long-lived secrets. The same events also drive webhooks and the APIs for anything GitHub doesn't do natively.