Bubble lets you revert changes to your application in case something went wrong. For instance, if you deleted a page and want to get it back, or realized that a change you pushed alienated your users, etc.
You can revert your app based on your plan. Some plans offer more history than others, but the mechanism is the same for all users.
As explained above, your application has at least two versions, live and test. Live represents the publicly-accessible version of the app, test is the version you make changes to. When you are ready, you can deploy your changes from test to live. Users on Team, Production, and Dedicated plans can have multiple development versions.
The name of the currently active branch is displayed in the toolbar, as well as at the top of the menu. Other versions can be selected from the menu below, or a new one can be created by clicking "Create a new version." The top portion of the menu allows you to perform operations relating to the current version: deploy it to live, create a save point, revert it to a previous time or save point (click "History"), or sync recent changes to live with it.
Clicking the "History" button gets you a popup that allows you to revert the current version to a previous point in time, as limited by your plan. Changes to Bubble apps are saved in a granular fashion, in the manner of an infinite undo. It's therefore possible to revert your version to any point in time. You can also create save points (directly from the version dropdown), which make it easy to revert the app to a particular state. You can think of save points as annotations, labels on a particular time and date you can apply for convenience. Histories are specific to versions, which means that when you deploy to live, live's will show your deployment but not development version save points leading up to it.
Please note that times are in your local timezone, and that reverting does not affect the state of the database.
When a user of a multi-version app deploys their version to live, the other versions become out-of-sync with live and need to be synced. Syncing a version with live incorporates the newly deployed changes, making it possible to deploy. In the event that one of the deployed changes conflicts directly, the user will be shown both options and prompted to choose which change to keep. Once an app has been synced it can be deployed.
The development version is the one you work on, while the live version is read-only and the one your users interact with in production. You restore your application in development mode, and if you need to deploy an older version of your application to production, you then deploy (push) to live (see above for more details).