Rolling back a bad prompt change with git revert

A prompt is code. When a tweak to your system prompt degrades output quality or breaks a downstream JSON parser, rolling back prompt changes with git is the fastest way to restore known-good behavior without redeploying from scratch. This guide walks through a concrete revert workflow using git revert, with verification steps that catch regressions before they hit production.

Treat prompts as code, not config

If your prompts live in a Notion doc or an admin console, you cannot audit them. Put each prompt in its own file under version control. Plain Markdown beats YAML for anything longer than a sentence—YAML’s indentation and quoting rules turn a simple edit into a syntax landmine. A workable layout:

prompts/
  system/
    classifier.md
    summarizer.md
  few_shot/
    tickets.json
  config/
    models.yaml

Commit prompt edits separately from application logic. A commit that touches both app.py and classifier.md forces you to untangle them during a rollback. Discipline here is what makes rolling back prompt changes with git a single command instead of a forensic exercise.

Why revert beats reset

git reset --hard deletes history. On a branch your team shares, or one feeding a deploy pipeline, that move forces everyone to rebase and silently drops the evidence of what broke. git revert appends a new commit that applies the inverse diff. The bad commit stays visible, the fix is explicit, and git bisect still works next time.

For prompt versioning this matters because regressions are often subtle. You want the trail: “commit 9f8e7d6 introduced concise tone, a1b2c3d reverted it.” That’s how you explain to product why Tuesday’s latency drop correlated with weird model output.

Step 1: Identify the offending commit

Narrow the log to the file in question:

git log --oneline -- prompts/system/classifier.md

Sample output:

9f8e7d6 tweak classifier tone to be more concise
a1b2c3d add fallback instruction for empty input
4d5e6f7 initial classifier prompt

If error reports started after 9f8e7d6, inspect the diff:

git show 9f8e7d6 -- prompts/system/classifier.md

When multiple prompt commits are suspects, use git bisect with your eval script as the test command. Mark the last good release as good, the broken HEAD as bad, and let git walk the history:

git bisect start
git bisect bad HEAD
git bisect good 4d5e6f7
# git checks out a commit; run eval, then:
git bisect good  # or bad

This finds the exact commit without guesswork.

Step 2: Isolate the rollback on a branch

Never revert straight to main without a validation gate. Create a topic branch:

git checkout -b revert/classifier-9f8e7d6

The branch is cheap insurance. If the revert conflicts with later legitimate edits, you can experiment freely and delete the branch if needed.

Step 3: Execute the revert

Run revert on the targeted commit:

git revert 9f8e7d6

Git prefills the message Revert "tweak classifier tone to be more concise". Append a reason:

Revert "tweak classifier tone to be more concise"

Root cause of malformed JSON on 20% of support tickets.

If the commit you’re reverting is not prompt-only, use -n to stage without committing:

git revert -n 9f8e7d6
git restore --staged app.py   # keep app changes out
git checkout -- app.py
git commit -m "Revert prompt edit from 9f8e7d6"

Conflict handling: if git stops with CONFLICT, open the file, resolve to the pre-bad text, git add it, and git revert --continue. To bail: git revert --abort.

Step 4: Validate with an eval harness

A reverted file is not proof of restored behavior. Build a tiny test set:

[
  {"input": "Refund not received", "expect_contains": "billing"},
  {"input": "App crashes on launch", "expect_contains": "bug"},
  {"input": "", "expect_contains": "cannot process"}
]

Load the prompt and run cases against an OpenAI-compatible endpoint. If you route test traffic through n4n.ai, its per-token usage metering keeps cost visible during repeated eval runs, and it forwards provider cache-control hints so identical prompt prefixes hit cache instead of billing twice.

import json, os, requests

with open("prompts/system/classifier.md") as f:
    system_prompt = f.read()
with open("tests/classifier_cases.json") as f:
    cases = json.load(f)

endpoint = os.environ["OPENAI_BASE_URL"]
api_key = os.environ["OPENAI_API_KEY"]

fails = 0
for c in cases:
    r = requests.post(f"{endpoint}/chat/completions",
        headers={"Authorization": f"Bearer {api_key}"},
        json={"model": "gpt-4o-mini",
              "messages": [
                  {"role": "system", "content": system_prompt},
                  {"role": "user", "content": c["input"]}],
              "temperature": 0})
    out = r.json()["choices"][0]["message"]["content"]
    if c["expect_contains"] not in out:
        fails += 1
        print(f"FAIL: {c['input']!r} -> {out!r}")

print(f"{len(cases)-fails}/{len(cases)} passed")

Run this on the revert branch and on main. You should see the failure count drop to zero after revert. Keep the harness in the repo; it becomes your prompt CI.

Step 5: Confirm file equality to last known-good

Verify the reverted content matches the state before the bad commit:

git diff a1b2c3d -- prompts/system/classifier.md

Empty output means the prompt is byte-identical to the last good version. If later commits added unrelated improvements, cherry-pick those after confirming they don’t depend on the reverted text.

Step 6: Open a pull request with evidence

Push and open PR:

git push origin revert/classifier-9f8e7d6

Title: revert: classifier prompt 9f8e7d6. Body must include the eval diff (failed on main, pass on branch) and the incident link. Require a reviewer to run the harness locally. A rollback without repro is just a guess.

Step 7: Merge, tag, and monitor

After green CI, merge. Tag the prompt version so logs can reference it:

git tag -a prompt-classifier-v1.2 -m "Revert concise tone regression"
git push origin prompt-classifier-v1.2

Watch production error rates for the next hour. If the regression was real, you’ll see the malformed-output metric fall.

Verification checklist

• git log shows a revert commit with explicit reason
• Eval harness fails on main, passes on revert branch
• git diff against pre-bad commit is empty for prompt file
• PR contains repro output, not anecdotal claims
• Tag pushed for traceability

Common pitfalls

Don’t edit the prompt in the model provider’s UI and call it fixed. The next deploy from git overwrites it. Don’t use git reset on shared branches to “tidy” history—you’ll orphan teammate work. Rolling back prompt changes with git only holds if the repository is the sole source of truth.

Avoid bundling model upgrades with prompt fixes. If you switch from gpt-4o to gpt-4o-mini in the same commit as a prompt revert, you can’t tell which change fixed the bug. Keep a models.yaml sidecar and change it deliberately.

Operational takeaway

Prompt versioning is incident response. The cycle is revert, verify, document. Spending an hour writing a 30-line eval harness pays back the first time a silent regression reaches your users. Git gives you the undo button; your job is to press it with proof.