Version Control (legacy)
Last updated
Was this helpful?
Last updated
Was this helpful?
Watch out
We are investigating bugs that occur during the merge process - this can lead to unexpected behavior, especially for more complex merge situations. If you merge and you suspect a bug, you are able to revert 'live' (or a version) back to a previous point in time. Note that it's also possible to copy elements / workflows / etc. from one version into another.
Legacy feature: this article refers to a legacy version of Bubble's Version Control system, and is noe officially support or updated anymore. Please see the article series below for more information about the new Version Control system.
Article series:
Every Bubble app has at least two versions, live (the version exposed to the world) and at least one development version, to which you make changes. All apps by default come with a single development version, called "test," although if you are on a Professional, Production, or Dedicated plan, you can create more. On these plans, if you were to delete a development version, it would not affect your live app in any way.
Within a version, Bubble lets you revert changes to your application in case something went wrong. Save points make it easy to revert to particular point, but since changes are stored continuously, you can revert to any specified time. How far back in time you can revert is determined by your plan.
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.
When building an app with multiple development versions, any version can be deployed to live. And, each version will have its own save points and reversion history. You can add the changes from any development version to the current development version.
Functionality related to version control can be found in the version control dropdown, found just to the left of the preview button:
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.
Known Issue
After merging two development versions, the Issue Checker in the newly combined version may not update right away. In these situations, if you want to be extra sure that any issues are caught in the merged version, our suggestion is to visit each page in the editor - visiting a page will should cause the Issue Checker to run for that page.
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.
A merge is when you add changes from one version into another version. For example, let's say I made some updates to my app in Version A. If I want to include those changes in my Development version, I would merge Version A into Development.
A conflict occurs when the same element or workflow has been changed in different ways in both branches involved in a merge. For example, let's say I have a blue Login Button in Version A and I create Version B from Version A. I then change the color of this Login Button to red in Version A and green in Version B. If I try to merge Version A into Version B, Bubble does not know what color the Button should be so it raises a conflict. To resolve the conflict, you must choose whether you want to go with the change to red in Version A or the change to green in Version B.
Development is a 'core environment' for your Bubble app. This is where you make changes to your app, as well as preview those changes. You'll know you are in Development when previewing your app because you will see /version-test in your apps URL. Development is also the default 'version'
Live is a 'core environment' for you Bubble app. This read only version is what your app looks like on the web. As such, changes to your app cannot be made directly to Live (outside of a few settings and App Data), but instead by deploying changes from your Development environment to Live.
A custom version is a 'branch' or copy of your app. Versions allow you to make changes to an app in isolation from any other version of your app. When you are happy with the changes you have made in one version, you can merge this version into your Development version so that it can be Deployed to Live.
Generally speaking, we highly recommend keeping your Development version as a “Main” version of your app. Development should be the branch you merge other versions into, create other versions from, and (almost always) the only version that deploys to Live.
If you want to create a new feature or a deploy a quick fix, we recommend the following approach:
Create a new version named after the feature you are working on from Development. This is done by selecting Development in the version control dropdown and creating a new version.
Work on that new version and, when ready, merge this version into Development
Review your updated Development version to ensure that your changes were successfully added and that everything works as expected
Visit all pages and tabs that could have changed in your editor to make sure the proper updates have been made. Some elements or issues might take a little time to appear for large apps.
Deploy your Development version to Live
Delete the feature version you used.
For subsequent feature work, create new versions off of the updated Development version
If you want to deploy a quick fix, but there is work in Development that is not yet ready to be deployed, we recommend the following approach:
Create a new version named after the fix you are working on from Live. This is done by selecting Live in the version control dropdown and creating a new version.
Work on that new version.
When you are ready to deploy, re-visit any pages or tabs that may have changed to ensure all updates have been made.
Deploy this working version to Live
Confirm that Live is behaving the way it should.
Merge this version into Development so that the next time you deploy Development to Live, your Development version contains the bug fix.
Delete the quick fix version you used.
Every time a version is merged into Development, we recommend syncing all other active versions with Development. To do this, navigate to an active version and merge Development into your version. This will lessen the amount of potential conflicts when you merge your active branch into Development.
We recommend using a version per feature rather than a version per developer because, in general, things get more complicated the longer different versions exist in parallel as more changes are made.
For similar reasons, we recommend keeping the lifetime of versions (other than Development and Live) as short as possible.
We also recommend that if you are working on a fix or feature in one version, that you do not edit any of the same items (elements, workflows, page, etc.) in another version. This will help to limit the number of conflicts that are raised when eventually merging the two versions.
Summary: All development versions share a common "test" database, although data associated with custom types you've created remain associated with specific versions. This means that although records of "userA-type' will exist in the same database referenced by userB, they will not show up in userB's version until userB syncs.
Detailed explanation: As noted above, every app has a live version and at least one development version. Records in the live database are independent of records in the development database. You can copy the live database to replace the development database or vice versa, but, for example, a user signing up in your live version will not automatically also create a record in your development version.
But what happens with multiple development versions? A principle to keep in mind is that all your development versions share the same "test" database but data associated with custom types remain associated with specific versions. To explain this further, here are a few scenarios (assuming A and B are both development versions of an app):
A is your main development branch and has a certain set of custom data types with different fields, and a number of records in it. When you create a new version, B, based off of A, B will also have those same custom data types, fields and records
After creating B from A, if you add new records to B of an existing data type, those new records will show up to A as well
Let's assume that A has a custom data type "Employee" with a set of fields. B is created from A, so B also has the Employee data type. If you add the new field "Birthday" (type text) to Employee in A, it will not automatically show up in B.
If you then add a new field "Birthday" (type text) to Employee in B, it will not refer to the same "Birthday" field from A, meaning that for the same record, A and B have their own independent "Birthday" fields that store data independently
Let's assume that B has already been created from A. If you then add a new custom data type "Project" in A, it will not automatically show up in B
However (and this is the tricky part!), if you created a new custom data type "Project" in B as well, it will refer to the same Project as A!
The process of publishing the changes in a version to the web. Note, if changes exist in Live that do not exist in your version, we will warn you that your version if out of sync with Live. To fix this, merge Live into your version.
If you notice that anything was not added after the merge, please visit our to get in touch with a member of our Support team, so we can investigate this situation as part of our ongoing work to improve the reliability of this feature
