Can we go back to the version that worked?

The model broke something and I cannot get it back is one of the most common emergencies in this kind of work. It is usually three emergencies wearing one coat. Something changed in the code in your folder, or in the version your users are running, or in the data. Each has its own way back, and mixing them up turns a small mistake into a large one.

Save points

Git records snapshots of tracked files, called commits. The commands below use the disposable page folder from the earlier exercise, containing index.html; do not initialize a second repository inside an existing project. Before the first one, make a file called .gitignore listing node_modules and .env, so that downloaded packages and secrets stay out. A later chapter explains why .env matters so much.

git init
git add .gitignore index.html
git diff --cached
git commit -m 'save the initial page'

The habit that makes everything else possible is committing before you hand the project to a model. Then everything it does is a difference you can read.

git status
git diff

status distinguishes staged changes, unstaged changes and untracked files. Plain diff shows unstaged changes; diff --cached shows what is staged for the next commit. Read the diff before you keep anything, the same way you would read a letter before signing it.

Undoing what is not committed

By default, git restore copies a file from the index, Git's staging area, into the working tree. To explicitly restore the last committed version of our disposable example file, name HEAD as the source:

git restore --source=HEAD --worktree index.html

This replaces the working-tree file and leaves the index unchanged. Inspect both git diff and git diff --cached first; a staged version may differ from HEAD. Uncommitted working-tree edits may have no recovery copy, so discard only the small exercise change you intended to undo. If you need to set work aside, git stash push -u includes tracked changes and untracked files; ignored files are still excluded. git stash apply restores that saved work and leaves the stash available. Check for conflicts before dropping the saved entry.

Undoing what is committed

git log --oneline
git revert a1b2c3d

The log lists commits with short ids. revert does not erase anything. It makes a new commit that does the opposite of the one you name, so history stays true, nobody else's copy is rewritten, and if the revert itself was a mistake, you can revert the revert.

You will find advice telling you to reach for git reset --hard or a force push. Those rewrite or discard history. They have their uses, and you will recognise them once you know git well. As a first move when something is broken, they can turn a recoverable mistake into one that is not. Start with status, diff, stash and revert.

For an experiment, create a branch with git switch -c try-search. Commit or stash its work before switching back to your original branch: uncommitted changes can otherwise follow you, or Git may refuse the switch.

The deploy is a separate copy

Reverting a commit changes your repository. It does not change what your users are looking at. The running site is a build made from some commit at some moment, and it keeps running until something replaces it.

If your host deploys on every push, the revert commit triggers a new build, which takes time and can fail for its own reasons. Most hosting platforms also keep previous deployments and let you put one back in place, usually called rollback or promote. That is faster, because nothing is rebuilt. Traffic is pointed back at a build that already worked.

So when production breaks, there are two steps in two places. If the previous deployment is compatible with the current data, rolling back can restore service while you prepare a fix. Revert or fix the code in Git too so a later push does not restore the bug. If you only roll back, the next deploy restores the bug. Find the rollback button in your host's dashboard on a calm day, before you need it.

Data does not roll back

Neither git nor a deploy rollback touches the database. Imagine a bad version of the to-do app that marked every task as done for twenty minutes before you noticed. Rolling the deploy back stops more tasks being marked. The ones already marked stay marked.

Repairing data is a third operation. It needs either a record of what changed or a backup you have actually restored before, which is the subject of a later chapter. There is one more trap here. If the bad version also changed the shape of the database, rolling back the code can leave old code facing a table it does not understand. That is why schema changes are designed to work with the code on both sides of them, which the migration chapter shows step by step.

Try it

In your project, run git status. For the disposable page folder, make a small change after the initial commit, read it with git diff, and restore only that file. In a real project, inspect existing work before discarding anything. Finally, open your hosting dashboard and find the list of previous deployments.