Why CLI and Git deploys feel like two separate platforms, and the single workflow that keeps everything in sync.

Recommended Workflow — Keeping Preview & Production in Sync

If it feels like two systems are working separately instead of in sync, that feeling is correct. This page explains why, and gives the one workflow that fixes it.

Why it feels like two platforms

There are two different ways to create a deployment, and they don't share a source of truth:

Method	What it ships	Stamped with
CLI (`vercel`)	Whatever is in your local folder right now	Your current `HEAD` commit
Git (push a branch)	A committed, pushed state	The pushed commit

Use both and you get two parallel deployment lineages that don't line up. That's exactly why the commit messages felt stuck on CLI previews, and why it feels like two platforms — in effect, it is.

The principle: one source of truth

Pick one way to deploy. For a project that already lives in GitHub and is wired to Vercel, that source of truth should be Git. Let Git drive every deployment, and demote the CLI to an occasional helper tool rather than a second deploy path.

The whole workflow

edit on dev  →  commit + push  →  Vercel auto-previews  →  test  →  merge dev→main  →  production

Daily loop (just normal Git)

# on your dev branch
git add .
git commit -m "intune panel: lock read-only fields"
git push

That push auto-builds a preview. Test it at your dev branch URL — give the branch a fixed domain (Settings → Domains) so it's always the same link.

Promotion = merging the PR

When a feature is solid, open a pull request from dev into main and merge it. That merge is the promotion to production. No vercel --prod, no manual promote step, no --meta flags.

Why this is both the best and the easiest

One lineage. What's in Git is what's deployed — the "two systems" feeling disappears.
The commit-message problem solves itself, because every deploy is a real commit.
Promotion is something you already know (merge a PR), not a separate platform concept.
Colleague-friendly. Anyone can read the current state straight from the Git history.

The CLI doesn't go away — it just stops deploying

Keep the CLI for what it's genuinely good at; stop using it to push code:

Keep using	Stop using
`vercel rollback` — revert prod fast	`vercel` (bare) — deploys a parallel preview
`vercel pull` — sync env vars locally	`vercel --prod` — deploys a parallel production build
`vercel logs` — inspect a deployment
`vercel list` — see what's deployed

Optional: a manual gate on production

If you want a click before prod goes live even after a merge, disable Auto-assign Custom Production Domains (Settings → Environments → Production → Branch Tracking). Merging then builds a staged production deployment that you promote from the dashboard.

For "easiest," leave this off — testing on the dev preview already catches problems, and instant rollback is your safety net if anything slips through.

The short version

Stop deploying with the CLI. Push to dev, merge to main.

That's the sync that was missing.

Vercel CLI — Preview-then-Promote Workflow — the terminal-driven flow (now a helper, not the default)
Vercel — GitHub Branch Preview Workflow — the branch/dashboard flow this page recommends
Vercel CLI — Fixing Repeated Commit Messages on Previews — the symptom that hinted at the parallel-lineage problem

Recommended Workflow

On this page