Workflow: PRs, review, Conventional Commits
GitHub Flow, good pull requests, standard messages and semver.
Updated
What a workflow is
A workflow is how a team organizes its branches, review and delivery. The most common one today for web apps — and the one Vercel supports natively — is GitHub Flow.
GitHub Flow, step by step
mainis always deployable.- For any change, you create a branch from
main. - You commit and push.
- You open a Pull Request (PR).
- CI runs automatically (lint, tests, build) + Vercel creates a preview deploy with its own URL.
- Teammates review it.
- Merge into
main→ automatic deploy to production.
Kinds of workflow — a comparison
| Workflow | What it looks like | When |
|---|---|---|
| GitHub Flow | main + short branches + PRs |
web apps with continuous deployment — the default |
| Trunk-based | everyone makes small commits directly (or nearly) on main, with feature flags |
mature teams, very good CI |
| Git Flow | main, develop, release/*, hotfix/* |
products with rare releases (desktop apps, libraries) — heavy for the web |
A good Pull Request
- Small — under ~400 changed lines; big reviews become superficial.
- A clear title + a description: what, why, how you tested it, screenshots for UI.
- A single topic — don't mix a refactor with a feature.
- Green CI before asking for review.
Conventional Commits
A standard format for messages, readable by people and tools:
<type>(<optional scope>): <description>
feat(cart): add discount coupons
fix: round the total with VAT correctly
docs: update the README
refactor(auth)!: remove the old sessions ← ! = breaking change
| Type | For |
|---|---|
feat |
a new feature |
fix |
a fixed bug |
docs |
documentation |
refactor |
restructured code, no change in behavior |
test |
tests |
chore |
dependencies, config, tooling |
perf |
performance |
A bonus: they can automatically generate the changelog and the version (semver): fix → patch (1.0.1), feat → minor (1.1.0), ! → major (2.0.0).
Tools that keep quality up
- CI (GitHub Actions): runs lint, typecheck, tests and the build on every PR.
- Branch protection on
main: forbids direct pushes, requires review + green CI. - Pre-commit hooks (lefthook, husky): run lint/format before each commit.
Summary
- GitHub Flow: branch → PR → CI + preview → review → merge → deploy.
- Small PRs with context; Conventional Commits for messages.
- Protect
main: CI + review required.