Undoing a Change

Sometimes a change goes wrong and you need the earlier version back. This page explains every way to undo a change on an Insites instance, what each one really does, and the habits that make undoing easy. You do not call the tools yourself: describe what you want in plain language and your AI picks the right tool. See CloudShell Tools for the full list.

Choose the Right Way

The right way to undo depends on how the change reached your instance.

Revert a Commit with GitHub

If your instance is connected to a repository through the Insites GitHub App, your AI can revert a commit with the insites_github_revert tool. It needs two things: the instance and the commit to undo. Your AI can find the commit with insites_github_commits.

Show me the last five commits. Then revert the most recent one
and tell me when the deploy has finished.

What a Revert Does

• It looks at the commit you chose and finds how the repository looked just before that commit.
• It adds one new commit to the branch your instance watches. The files in that new commit are exactly the files from just before the chosen commit. The commit message is Revert commit followed by the short commit id.
• It does not rewrite history. The branch only moves forward and nothing is force-pushed. Every older commit stays in the history, so you can still read it.
• It deploys like any other push. The tool itself does not deploy, but the new commit lands on the watched branch, and every push to the watched branch deploys automatically. Ask your AI to check the deploy, for example: Did the revert deploy?

Note: A revert puts the whole repository back to how it was before the commit you chose. It is not the same as a standard git revert, which undoes only that one commit. If you revert an older commit, every commit after it is undone too: the changes from those later commits are removed from your files, and the earlier files are deployed. The later commits stay in the history. To undo one change and keep later work, see Undo One File Without Losing Later Work below.

Limits

• You cannot revert the very first commit in a repository, because there is no earlier version to go back to.
• If someone else pushes to the watched branch at the same moment, the revert fails instead of overwriting their commit. Ask your AI to list the commits again and try again.
• Reverting needs the Developer role or above on the instance, the same as deploying.

Undo One File Without Losing Later Work

With GitHub

To undo one file and keep every later change, ask your AI to commit the older version of that file:

1. List recent commits with insites_github_commits and find the last commit where the file was correct.
2. Read the file as it was at that commit with insites_github_pull. It can read from a branch or from an earlier commit.
3. Commit that older content with insites_github_push. It lands on the watched branch and deploys automatically.

Find the last commit where app/views/pages/index.liquid was correct.
Read the file as it was in that commit, commit it back to the
watched branch, and confirm the deploy.

Without GitHub

Deploy your own older copy of the file again. Small files go through insites_deploy or insites_sync_file. Large files go through an upload. An upload will not replace a file that CloudShell knows is already there unless you ask it to, so tell your AI that you want to replace the file.

Note: The deployment history records who deployed, when, and how many files. It does not store the contents of your files, so it cannot give you an older version back. Keep your own copy, or connect GitHub.

When a Deploy Fails

What happens next depends on how the deploy was started.

Automatic Rollback for Upload and Link Deploys

Upload and link deploys run as a background job. Your AI checks its progress with insites_deploy_status.

• Short service problems are retried. The job tries again up to three times before it gives up.
• A deploy the instance rejects is rolled back straight away. Trying again would fail the same way.
• A file the deploy replaced is put back from the 30-day copy, byte for byte.
• A file CloudShell has no record of is emptied, not deleted. This usually includes a file the deploy created, because CloudShell cannot be sure it was not there before.
• If a file was there before but no copy was kept, CloudShell does not guess. It leaves the file as it is and alerts the Insites team. The deploy then shows as failed in the deployment history, with a message that manual recovery is needed.

Fixing Other Failed Deploys

Ask your AI to check the deployment history and the instance logs. It can read the error, fix the file and deploy again. If the bad change came from GitHub, push a fix or revert the commit.

Show me the last five deploys and check the logs for errors.
Tell me what failed and fix it.

The 30-Day Copy

When a direct deploy replaces a file that CloudShell knows is on your instance, CloudShell saves a copy of the version being replaced. CloudShell knows a file is there when it deployed that file itself in the last 30 days. A file that reached your instance another way, such as from GitHub, may not be copied. The copy is deleted automatically after 30 days.

• Kept by: insites_deploy, insites_commit_upload, insites_upload_asset and insites_deploy_from_url.
• Not kept by: insites_sync_file, and deploys from GitHub. For GitHub, the repository history is your record.
• Used automatically when an upload or link deploy fails and is rolled back.

Note: There is no tool your AI can use to restore a file from the 30-day copy. If you need a file back from it, contact Insites support within the 30 days. Tell them the instance, the file path, and roughly when the deploy ran.

Habits That Make Undoing Easy

• Connect GitHub. Every change becomes a commit you can review and undo yourself. See Insites GitHub App.
• Build on staging first. Test every change on a staging instance before it goes to production. See Safety Rails for AI Builds and Staging vs. Production.
• Keep unfinished work off the watched branch. Push work in progress to another branch. Nothing deploys until it is merged into the watched branch.
• Check the commit list before you revert. Make sure you know which later commits a revert will also undo.
• Know where the deployment history is. Ask your AI to show recent deploys, so you can see which change to undo.
• Keep your own copy when you deploy directly. Without GitHub, your own copy is the fastest way back.

Related Pages

• About CloudShell - what CloudShell does and how it records every deploy.
• CloudShell Tools - every tool your AI can use, with example prompts.
• Insites GitHub App - connect a repository and deploy on every push.
• Safety Rails for AI Builds - the checks to make before your AI changes anything.
• Getting Set Up with AI - set up your AI assistant and CloudShell.