Bubble Docs
  • Introduction
  • New? Start Here
  • What is Bubble?
  • The Glossary
  • User manual
    • Getting started
      • What is Bubble?
      • Building for...
        • Web
        • Native iOS and Android
          • Mobile app quick start guide
          • What is a native mobile app?
          • Native mobile vs. web development
          • Differences in native and web elements
          • Native mobile app terminology
      • Building your first app
        • Planning features
        • Database structure
        • Design and UX
        • eCommerce and payments
          • Shopping cart
          • Checkout page
          • One-time payments
          • Subscriptions
          • Marketplace
      • Creating and managing apps
      • The Bubble editor
        • Tabs and sections
          • Design tab
            • The element tree
            • The property editor
          • Workflow tab
          • Data tab
          • Styles tab
          • Plugins tab
          • Settings tab
            • Application settings
              • Custom headers/body
              • Visual settings
              • Social media sharing
              • Translating your app
              • Email settings
              • Collaboration
            • Custom domain and DNS
          • Logs tab
        • Tools
          • Key features
          • The search tool
          • The Issue Checker
          • The element tree
          • The element property editor
          • The debugger
          • Notes
        • Previewing your app
      • Transitioning to Bubble from...
        • JavaScript
        • HTML and CSS
        • SQL
    • Design
      • Elements
        • Web app
          • The page
          • Containers
            • Groups
            • Repeating groups
            • Table elements
            • Popups
            • Floating groups
            • Group focus
          • Visual elements
          • Input forms
            • Text and numbers
            • Dates and time
            • File uploads
            • Selection controls
        • iOS and Android app
          • The view
          • Containers
          • Visual elements
          • Input forms
          • Mobile reusable elements
        • The element hierarchy
          • The element tree
        • Reusable Elements
      • Styling
        • Color variables
        • Font variables
        • Styles
        • Custom Fonts
      • Responsive design
        • Building responsive pages
        • Legacy articles
          • The Basics (Legacy)
          • Building Responsive Pages (Legacy)
          • Migrating Legacy Pages
          • Tips When Designing (Legacy)
      • Templates
      • The Component Library
      • Importing from Figma
    • Data
      • The database
        • Data types and fields
        • Creating, saving and deleting data
        • Finding data
        • Displaying data
        • Protecting data with privacy rules
        • The database editor
        • Export/import data
          • Exporting data
          • Importing data (CSV)
        • Working with location data
        • Using Algolia
        • Database structure by app type
          • Marketplace Apps
          • Directory & Listings Apps
          • Social Network Apps
          • SaaS Apps
          • Project Management Apps
          • CRM Apps
          • Professional Services Apps
          • On-demand Apps
          • Documentation/ CMS Apps
          • Applicant Tracking System (ATS) Apps
          • Portfolio Apps
          • Gallery Apps
          • Online Store / Ecommerce Apps
          • Blog Apps
          • Messaging App
          • Dashboards
          • Building Block Apps
          • Bubble as a backend
      • Files
      • Images
      • Static data
        • App texts (translations)
        • Option sets
      • Temporary data
        • Custom states
        • URL parameters
      • User accounts
        • Authentication plugins
          • Facebook plugin
          • Fitbit plugin
          • Google plugin
          • Instagram plugin
          • LinkedIn plugin
          • Pinterest plugin
          • Slack plugin
          • Wistia plugin
          • YouTube plugin
        • Cookies set by Bubble
      • Time, dates and time zones
    • Logic
      • The frontend and backend
      • Workflows
        • Events
          • Frontend events
            • Recurring workflows
            • Custom events
          • Backend events
            • Database trigger events
        • Actions
        • API Workflows
      • Dynamic expressions
      • Conditions
      • Navigation
        • Single-page applications (SPA)
        • Multi-page applications
        • Page slugs
      • Device resources
        • Location services
        • Camera/photo library
    • Workload
      • Understanding workload
        • Activity types
        • The workload calculation
        • Client-side and server-side processing
      • Tracking workload
        • Measuring
          • Using App Metrics
        • Monitoring
          • Workload notifications
          • Infinite recursion protection
      • Optimizing workload
        • Optimization framework
        • Optimization checklist
          • Page load
          • Searches
          • Workflows and actions
          • Backend workflows
        • Agency showcases
          • Minimum Studio
          • Neam
          • Support Dept
    • Security
      • Bubble's security features
      • Planning app security
      • Client-side and server-side
      • Bubble account security
      • App security
      • Page security
      • Database security
      • API security
        • API Connector security
        • Data API security
        • Workflow API security
      • Flusk
        • Overview
        • Flusk plan features
        • Getting started with Flusk
        • Flusk security tools
          • The Issues Explorer
          • Issue details
          • Tools and settings
            • Pages rating
            • Database rating
        • Flusk FAQ
      • Cookies
      • Security checklist
    • Previewing your app
      • Previewing a web app
      • Previewing a mobile app
    • Publishing your app
      • Web app
      • Native mobile app
        • Global native mobile settings
        • iOS App Store
        • Google Play Store
        • Publishing FAQ
    • AI
      • Generate apps with AI
        • About AI app generation
      • AI page designer
      • Connect to AI agents
    • Maintenance
      • Collaborators
      • Version control
        • Best practices: Version control
        • Transitioning from the legacy version control
        • Terminology: Version control
        • Version Control (legacy)
      • Commenting
      • Database maintenance
        • Copying the database
        • Restoring database backups
        • Bulk operations
          • Bulk operation methods compared
        • Wiping change history
      • Performance
        • Hard limits
        • Capacity Usage (legacy)
        • Notes on queries
      • SEO
        • Introduction to SEO
        • SEO: App
        • SEO: Page
      • Testing and debugging
        • Introduction to testing and debugging
        • The debugger
        • The server logs
        • Supported browsers
      • API workflow scheduler
    • Integrations
      • API
        • Introduction to APIs
          • What is a RESTful API?
        • The Bubble API
          • Bubble API terminology
          • Authentication
            • How to authenticate
            • No authentication
            • As a User
            • As an admin
          • The Data API
            • Data API Privacy Rules
            • Data API endpoints
            • Data API requests
          • The Workflow API
            • Workflow API privacy rules
            • Workflow API endpoints
            • API workflows
              • Creating API workflows
              • Scheduling API workflows
              • Recursive API workflows
              • API Workflow Scheduler
              • Case: Stripe notifications
        • The API Connector
          • Authentication
          • API Connector security
          • API guides
            • OpenAI
              • Authentication
              • Calls
                • ChatGPT
                  • Chat
            • Google Translate
              • How to setup Google API keys
          • Streaming API
        • API security
        • Plugins that connect to APIs
        • API Glossary
      • Plugins
        • What Plugins Can Do
        • Installing and using Plugins
        • Authentication plugins
        • Special Plugins
      • SQL Database Connector
      • Bubble App Connector
      • WorkOS
        • WorkOS SSO
        • WorkOS API
    • Infrastructure
      • Sub-apps
      • Bubble release tiers
      • Hosting and scaling
        • How Bubble hosting works
        • Scaling with Bubble
        • CDN (Cloudflare)
        • Bubble app names
        • Domain and DNS
      • Compliance
        • GDPR
        • SOC 2 Type II
        • HIPAA
        • Other frameworks and standards
    • Bubble for Enterprise
      • Hosting and infrastructure
        • Dedicated instance
          • The Dedicated editor experience
          • Technical specs
          • Main cluster dependencies
          • Customizable options
          • Migration process
            • Pre-migration
            • During migration
            • Post-migration
      • Security and compliance
        • Single sign-on (SSO)
        • GDPR
        • SOC 2 Type II
        • HIPAA
        • Other frameworks
        • Bubble's security features
      • Admin and collaboration
      • Priority support
      • Billing and Payment Guideline for Dedicated Instances
  • Core Reference
    • Using the core reference
    • Bubble's Interface
      • Design tab
      • Design tab (Legacy)
      • Workflow tab
      • Data tab
      • Styles tab
      • Styles tab (Legacy)
      • Plugins tab
      • Settings tab
      • Logs tab
      • Template tab
      • Toolbar
      • Top and context menu options
      • Deployment and version control
        • Deployment & Version Control Dropdown (legacy)
      • Notes
    • Elements
      • Native mobile elements
        • View element
        • List component
      • General properties
      • General properties (Legacy)
      • Styling properties
      • Styling Properties (Legacy)
      • Responsive Properties
      • Responsive Properties (Legacy)
      • Conditional formatting
      • States
      • Page Element
        • Page Element (Legacy)
      • Visual Elements
      • Containers
      • Container Layout Types
      • Containers (Legacy)
      • Input Forms
      • Reusable Elements
      • Element Templates (legacy)
    • Workflows
    • Events
      • General events
      • Element events
      • Custom events
      • Recurring event
      • Database trigger event
    • Actions
      • Account
      • Navigation
      • Data (things)
      • Email
      • Element
      • Custom
    • On-device resources
    • Data
      • Data Sources
      • Operators and comparisons
      • Search
      • Privacy
    • Styles
    • API
      • The Bubble API
        • The Data API
          • Authentication
          • Data API endpoints
          • Data API requests
        • The Workflow API
      • The API Connector
        • Authentication
        • Adding calls
    • Bubble-made Plugins
      • AddtoAny Share Buttons
      • Airtable
      • API Connector
      • Blockspring
      • Box
      • Braintree
      • Bubble App Connector
      • Chart.js
      • Circle Music Player
      • Draggable Elements
      • Dropzone
      • Facebook
      • Fitbit
      • Full Calendar
      • Google
      • Google Analytics
      • Google Optimize
      • Google Places
      • Ionic Elements
      • iTunes
      • Slidebar Menu
      • LinkedIn
      • Localize Translation
      • Mixpanel
      • Mouse & Keyboard Interactions
      • Multiselect Dropdown
      • Progress Bar
      • Rich Text Editor
      • Rich Text Editor (Legacy)
      • Screenshotlayer
      • SelectPDF
      • Slack
      • Segment
      • Slick Slideshow
      • SQL Database Connector
      • Star Rating
      • Stripe
      • Tinder-like Element
      • Twitter
      • YouTube
      • Zapier
    • Application Settings
      • App plan
      • General
      • Domain / email
      • Languages
      • SEO / metatags
      • API
      • Collaboration
      • Sub-apps
      • Versions
  • Account & Marketplace
    • Account and billing
      • Pricing and plans
        • Plans and billing
        • Billing cycle
        • FAQ: Pricing and Workload
      • Account Management
      • Building Apps for Others
      • Selling on the Marketplace
      • Plans & Billing (legacy)
    • Official Bubble Certification
      • Hiring certified developers
    • Building Plugins
      • The Plugin Editor
      • General Settings
      • Updating to Plugin API v4
      • Adding API Connections
      • Building Elements
      • Building Actions
      • Loading Data
      • Publishing and versioning
      • Github Integration
    • Building Templates
    • Application and data ownership
    • Marketplace policies
    • Bug reports
  • Vulnerability Disclosure Policy
  • Beta features
    • About the Beta features section
    • Native mobile apps
Powered by GitBook
On this page
  • Versions
  • The Version Control Dropdown
  • The History Popup
  • Syncing a Version with Live
  • Version Control Best Practices
  • Definitions
  • Best Practices
  • Note on databases of development versions

Was this helpful?

  1. User manual
  2. Maintenance
  3. Version control

Version Control (legacy)

Last updated 1 year ago

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.

Versions

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.

The Version Control Dropdown

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.

FYI

When you merge two versions, especially with big apps and with larger differences between the versions, the editor will be noticeably slower for a little while after the merge as Bubble does a lot of calculations behind-the-scenes. This should resolve itself after a little while.

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.

The History Popup

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.

Syncing a Version with Live

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.

Version Control Best Practices

Definitions

Merge

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.

Conflict

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.

Deploy to Live

Development

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

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.

Custom version

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.

Best Practices

  • 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.

Note on databases of development 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

Support center
Learn more here.
Version control