---
title: "Undo a Change"
description: "Undo the failure commit with Git revert and check the corrected deployment. Preserve unrelated work and the existing commit history."
canonical_url: "https://vercel.com/academy/build-and-launch-with-ai/undo-a-change"
md_url: "https://vercel.com/academy/build-and-launch-with-ai/undo-a-change.md"
docset_id: "vercel-academy"
doc_version: "1.0"
last_updated: "2026-09-25T16:42:54.356Z"
content_type: "lesson"
course: "build-and-launch-with-ai"
course_title: "Build and Launch with AI"
prerequisites:  []
---

<agent-instructions>
Vercel Academy — structured learning, not reference docs.
Lessons are sequenced.
Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume.
The lesson shows one path; if the human's project diverges, adapt concepts to their setup.
Preserve the learning goal over literal steps.
Quizzes are pedagogical — engage, don't spoil.
Quiz answers are included for your reference.
</agent-instructions>

# Undo a Change

# Undo a change

We found the preview failure in one dedicated commit. We'll undo that commit, deploy the correction, and check that sending works again. Git can record the reversal alongside the original change, giving us a clear recovery history.

In the website folder, check the branch and recent commits:

```sh
git branch --show-current
git status
git log -4 --oneline
```

The branch must be `form-recovery`, and the working tree should be clean. Keep the failure commit identifier from 5.3 available. If the branch or local changes differ, resolve that before continuing.

## Outcome

Revert the known failure commit and verify the corrected preview without discarding unrelated work.

## Hands-on exercise 5.4

### Identify what to reverse

A revert creates a new commit that undoes the changes from a selected commit. The original stays in the history, so we can see both the mistake and its correction, even after sharing the work.

Inspect the exact commit from our diagnosis. Replace the placeholder with its recorded identifier:

```sh
git show --stat PASTE_FAILURE_COMMIT_HERE
git show PASTE_FAILURE_COMMIT_HERE -- app/actions/interest.ts
```

The patch should contain only the preview-only key expression from 5.3. If it includes other work, stop and identify the correct dedicated commit. Selecting whatever happens to be the latest commit could reverse something unrelated.

Keep the production branch untouched during this exercise. The failure and its correction both belong on the recovery branch; production already has the working email configuration.

### Create the correction

With the right identifier and a clean working tree, run:

```sh
git revert --no-edit PASTE_FAILURE_COMMIT_HERE
```

`--no-edit` accepts Git's generated revert message, which references the original change. This command writes a new commit. It doesn't delete earlier history or require a force push. See [Git's revert documentation](https://git-scm.com/docs/git-revert) for the command's behavior.

Inspect the new commit and the action file:

```sh
git log -2 --oneline
git show --stat HEAD
git diff HEAD~1 HEAD -- app/actions/interest.ts
```

The correction should restore `apiKey: process.env.RESEND_API_KEY`. The catalog still contains all three workshops because their release preceded the failure commit and isn't part of its patch.

If Git reports a conflict, read the troubleshooting guidance below. Don't use a reset to force the history back to an earlier point. We want to reverse this one intentional edit while keeping other saved work.

### Verify before deploying

Run the existing email-helper tests from 4.5:

```sh
npx tsx --test tests/course-interest.test.ts
```

Use the pnpm equivalent when appropriate. These tests check that the helper still handles the fake senders' results correctly. Inspect the adapter diff as well: the unit tests don't prove that a deployed environment supplies its settings correctly.

Open the local site if needed and confirm the three catalog entries remain. Check `git status` before deploying so the preview represents the saved correction.

### Deploy the recovered version

Run `vercel` and copy the new preview URL. Confirm that it belongs to the existing workshop project and uses the recovery commit. Open the new URL; the failed preview URL still identifies the older deployment.

Submit one controlled inquiry on the corrected preview. Check the acceptance message and owner inbox. If it remains unconfigured, inspect Preview's environment values and the deployment source before making another code change.

The new preview is the version we use to verify the recovery. Keep the failed URL in your private exercise notes as evidence of the earlier state, but don't share it as the current working site.

## Try It

Compare the failure and recovery notes. Record the original failure commit, its revert commit, and the corresponding preview URLs. Include the controlled delivery observation for the corrected deployment.

Return to the released branch after verification:

```sh
git switch main
git status
```

Substitute your actual production branch if needed. Leave `form-recovery` available as exercise history. It doesn't need to be merged because the production branch never received the intentional failure. Confirm production still points to the release from 5.2.

### Revert reports a conflict

A later edit may overlap the selected change. Git identifies the conflicted files with `git status`. For this exercise, `git revert --abort` cancels the in-progress revert and returns to the pre-revert state. Inspect the branch history and choose the correct commit before retrying. If a conflict needs manual resolution, review that specific overlap before continuing the revert.

### The new preview still fails

Check that the browser is on the corrected deployment URL. Inspect the deployed source identifier and confirm Preview still has the email configuration from Section 4. A provider rejection and a missing key have different runtime events; use the observed event to guide the next investigation.

## Commit

`git revert` has already created the correction commit. Don't add an empty commit afterward. Keep its identifier with the diagnosis and preview evidence. For a shared release, we'd review and deploy this correction the same way as any other code change.

## Done-When

- [ ] The selected failure commit is reversed by a new commit on `form-recovery`.
- [ ] The diff restores normal key lookup and preserves the three-workshop catalog.
- [ ] The corrected preview accepts an inquiry that reaches the owner inbox.
- [ ] The recovery is documented and production remains on its working release.

## Solution

After inspecting the recorded failure identifier, the recovery sequence is:

```sh
git revert --no-edit PASTE_FAILURE_COMMIT_HERE
git status
npx tsx --test tests/course-interest.test.ts
vercel
```

Replace the identifier placeholder and use the project's package manager. Review the new preview, verify the controlled send, then return to the production branch. Keep the saved diagnosis with the release notes for the workshop site.


---

[Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)