Question
Vercel Instant Rollback and Git Branch Desynchronization After Failed Framework Upgrade
Rin Moss
0 reputation · 08 Mar 2020, 22:15 UTC
85K views1
Loading…
0 reputation · 08 Mar 2020, 22:15 UTC
When using Vercel's Git integration with production deployments, a key interoperability question arises around the relationship between the production alias and the Git branch after an Instant Rollback. The Instant Rollback feature promotes an earlier immutable deployment to restore service without rebuilding, which means the production domain points to the older deployment's content-addressed artifacts.
However, this rollback operation only modifies which deployment the production alias references—it does not alter the Git branch or its commit history. The production branch remains at the failing upgrade commit, creating a potential state where the live production environment and the Git branch tip are misaligned.
This raises an unresolved operational question: after rolling back to a known-good deployment, does the next push to the production branch automatically redeploy the failing commit, effectively undoing the rollback? Or does Vercel provide any mechanism to synchronize the production alias with the older commit to prevent automatic redeployment of the broken code?
The core constraint is that deployments are immutable and content-addressed, while Git branches are mutable references. The production alias acts as a pointer to a specific deployment, independent of where the Git branch points. Understanding whether this design leads to persistent desynchronization is critical for reliable recovery workflows.
No. Vercel Instant Rollback repoints the production alias to an earlier immutable deployment; it does not move the Git branch, rewrite commit history, or prevent a future push from rebuilding the failing commit. Yes, the next push to the production branch can trigger a new build of that commit and, if auto-promotion is enabled, move the production alias off the rolled-back deployment. There is no rollback-only setting that pins the alias to an old commit while blocking builds of newer commits.
Confirmed: rollback is an alias operation. The production domain serves older artifacts while the branch tip remains at the failed framework-upgrade commit.
Likely: your production branch is mapped to the production alias and auto-deployment is enabled. Under that default, any new commit on the branch—including a force-push of the same SHA—can start a build and replace the alias.
git rev-parse origin/main
Replace origin/main with your production branch. Compare that SHA with the commit shown on the rolled-back deployment in the Vercel dashboard. Different SHAs confirm desynchronization.
Is auto-deployment enabled for your production branch, or is the project frozen or using manual promotion? If auto-deployment is off, the next push may not immediately undo the rollback, which changes how urgently you need a Git revert.
Do not force-push or rewrite history after a rollback; that can break deployments tied to previous SHAs and widen the mismatch.
Use comments to ask for clarification. Post a solution as an answer.
5,930 reputation · 09 Mar 2020, 02:06 UTC
After an Instant Rollback, Vercel only updates the production alias to point to the earlier deployment; the Git branch still references the failing commit. Because Vercel’s default “Deploy on Push” triggers a build whenever the branch tip changes, the next push (even an empty commit) will rebuild the current tip and redeploy the breaking code unless the branch is first moved back to a good commit. To keep the branch in sync you can either git revert the bad commit and push the revert, or reset the branch to the earlier SHA with git reset --hard <good‑sha> and force‑push (exercise caution on shared branches). Vercel does not provide an automatic realignment option.
vercel