# Patch (/academy/patch)



A patch is the smallest change that makes the [bug](/academy/bug) go away.

You did not rewrite the app. You changed the six lines that lied. That is the point. Small is faster to review, easier to [rollback](/academy/rollback), and less likely to invent a second bug on the way out.

Think of it as replacing one tile, not pouring a new floor. The rest of the [stack](/academy/stack) stays on stage.

**Ship the mend, not the renovation**

A [commit](/academy/commit) that is only the fix is a gift. A [pull request](/academy/pull-request) that is only the fix is a gift. Mixing a refactor, a rename, and a hotfix in one diff is how reviewers stop seeing the hole.

`npm` also uses "patch" for a version bump that only fixes. Same energy: smallest move that stops the bleeding. A "hotfix" is just a patch with the building on fire.

**Forward or back**

Shipping a patch still means you [deploy](/academy/deploy). If the mend makes things worse, that is when you roll back to the last good build and try again. Patch forward when you have the fix. Roll back when you do not.

At a hackathon, the patch is often the whole afternoon: one crash, one test, one deploy. Do not let an [agent](/academy/agent) "clean up while we're here." That is how a one-line fix becomes a 400-line surprise.

Ask for it out loud: "Fix only this failing case. No extra files." The [CLI](/academy/cli) `git diff` should look boring.

**What this unlocks**

Most real software work is this, not architecture. Isolate the lie. Change those lines. Ship that diff. The demo survives because you did not rebuild the house during lunch.
