# Restore an earlier version

Return an environment's whole job graph to a version committed earlier, covering what a restore replaces, what it never touches, and what to do when it refuses.

A restore returns a project environment's jobs to the configuration committed at a chosen point in its history.

Start from **Repository → History**: expand a commit's diff and choose **Restore this version**. Restoring needs configuration write access (the same permission that gates committing and discarding), and without it the control is replaced by a note explaining why.

A restore only ever changes your working copy. It never moves what Git has already committed, and it is scoped to the one project and environment you are viewing. You still choose what, if anything, to commit afterward.

![The repository History page listing three commits. The second is open, showing its added file as a diff and a Restore this version button.](demos/guides/repository-restore-an-earlier-version-light.png)
{mode="true" class="guide-image"}

## What a restore replaces

Your working copy's jobs become identical to the ones committed at that commit: the environment's **whole job graph**, not only the files that commit happened to touch. Every job the commit carries is taken from it in full: source, target, include and exclude lists, shared defaults, per-object overrides, and runs.

This is the part worth reading twice. The diff panel shows what changed *in that one commit*; the restore reconciles your working copy against everything that commit's configuration describes.

## Jobs missing from the commit are deleted

A job in your working copy that is absent from the commit you are restoring is deleted, along with all of its runs and their schedules.

Restore is the only control in Repository that deletes a job outright. Discarding a change or taking the committed version on the Changes page never removes a job, only individual objects inside one that still exists.

## Sources and targets are never touched

A restore never creates, changes, or removes a source or target connection.

If the commit names a connection your project no longer has, **nothing is restored at all**. The whole operation refuses rather than restoring the rest and quietly dropping the jobs that depended on the missing connection. Recreate the connection first, or restore a commit that does not depend on it.

## Generated files are not rolled back

Documentation, dbt models, and SQL are generated *from* your configuration when you next commit. They are not part of the job graph a restore reconciles, so restoring does not roll them back. They keep describing the last committed configuration until you commit again, at which point they regenerate to match.

Expect them to describe a newer configuration than the one you just restored, right up until that next commit.

## Restoring a commit that is not the newest

Restore an older commit and the restored objects will show as **conflicting** on the Changes page. That is the expected outcome, not a fault.

A restore changes only your working copy, never Git. Restoring an older commit therefore leaves your working copy holding older content than the branch tip actually has, and the conflict is Amfelt reporting that gap rather than hiding it. Review it on Changes and decide: commit the older configuration forward, or discard back to what is committed. Nothing is committed for you.

## When a restore refuses

A restore reads the committed configuration back and requires that reading it reproduce it exactly, the same guarantee every commit and import depends on. If it cannot, the restore refuses and changes nothing.

One message currently covers two causes, because they cannot yet be told apart from the commit alone:

- **The committed file was hand-edited** and no longer matches the form Amfelt writes. This is the more common cause. Commit the file again through Amfelt rather than editing it directly in Git.
- **The commit needs a source or target the project no longer has**, as above.

Check both: confirm the connections that commit needs still exist, and if the file was edited by hand, return it to a form Amfelt can reproduce. Then try again.

## Next

[Browse committed files](/docs/guides/repository/browse-committed-files/).