Introducing Bubble’s New Version Control

If you are on new version control, this is a bug. You should be able to use the same name for a branch as one that has been previously deleted.

Do you mind filing a bug report?

Hi! You should be able to move your app from Professional to the new Growth plan by navigating to Settings > App Plan and selecting the new Growth plan when upgrading your apps plan. Let me know if you have any issues

1 Like


Not sure if this is bug.

Copied three “on page load” workflows up from Main into a Hotfix. All good.

Then synced Live back to Main.

It did not recognise the steps from Live as identical (although I have seen it do this before) and so duplicated every step.

I have 2 branches:

  • Main development
  • Another branch for test
    I NEED to keep these 2 separated. I am currently blocked to work properly. How can I come back to the former branch manager?

Do you mind sharing a bit more about how you are currently blocked? Depending on your plan, you should have at least 1 more branch for development. This branch can be created from Main or from your test branch for any development work.

Hi @nickc, My entire app is built in development-2 (not the main branch). I’ve been stuck there since 2020 (Bug report #8967) because of the known version sync issues.

@nickc Should I bet my life’s work that there will be no issues?

I have three years of development work without ever syncing to main.

In short, yes. There is also a very safe way to do this.

Situation 1: Your Live = development-2 (ie no open work in that branch at the moment)

  1. In the more actions menu on Main, click “Reset to Live” to make your Main branch the same as whats in Live. You can now delete, or just sideline, the development-2 branch. You now have a clean Main to create new branches and start new development work.

Situation 2: development-2 has work that does not yet exist in Live

  1. In the more actions menu on Main, click “Reset to Live” to make your Main branch the same as whats in Live. This gives you a stable place to start the merge with development-2
  2. Create a new branch off of development-2 to save the work that exists in development-2
  3. Merge Main into development-2 using the “Sync with Main” action to ensure there are no conflicts. Since Main is up to date with Live from Step 1, there shouldn’t be any conflicts.
  4. Finally, merge development-2 into Main to get Main up to date with development-2. Once you are confident they are the same, you can go ahead and delete or sideline development-2 & remove the safety branch you created in Step 2.

Let me know if you have any questions


@nickc I’m going this route.

I think there will be conflicts. Right?

Main will look just like live. And since development-2 contains changes not yet in live, there will be conflicts here.

P.S. - I did steps 1 and 2 and it seems OK so far. Thank god…I’m scared.


So conflicts will only arise when something has been changed in different ways in two different branches - so it should be unlikely if the last deploy was made from development-2 But if there are, you’ll have the opportunity to preview what the conflict looks like if its resolved either way to help you make the right choice


Ok @nickc I followed your directions and this seems to have worked perfectly.

I’m still cautious of sync issue. However, I’m very impressed with step three which is used as a double check for syncing issues.

I’ll report back later, but if there’s no issues this update might be such a big deal. In a good way.

thanks Nick!

Thats great to hear! Let me know how it goes.

You should be.

Am not sure it really works as well as they think it does.

As in…I have already broken the sync.


@NigelG , Have you tried using a “down tree” merge to verify conflict before pushing “up tree”. It seems like a built in way to audit for sync issues.

It was Nicks recommendation (below) and seems legit.

It took me a while to understand how this audit works. This video is the best resource. The 2min mark is where it goes into the mini audit performed by bubble.

Thanks for sharing that there’s still sync issues. I had to manually go over each workflow and condition back in April of 2020 when I trusted the sync. It took me months of work to get it right…bubble helped me go over each item manually as well. This was honestly horrible…I couldn’t sleep.

I think transparency is the most important thing here. I hope others document sync issues in this forum. I think bubble should also post known issues in the docs (like they did in the past) to avoid major issues.

Hey Nigel - have you filed a bug report for the issue you encountered merging?

Sorry to be snarky @nickc but I stopped reporting editor Bugs when you stopped fixing them.

1 Like

This was a “down” tree. The merge back “down” from a Hotfix to Main doesn’t work very well.

I had, rather stupidly, assumed that enough people would have used the new VC by now to have ironed out the kinks.

Think I have gone to early on this, sadly. I have no time to test stuff for Bubble .

Nah, definitely broken.

Just had some merge conflicts (out of the blue) from Main to Branch. Selected to use the ones from Main (as they were correct) and they DID NOT get merged into the branch.

Had to recreate the branch from scratch.

Which is now impossible. As my previous version (version-qa) is now called version-12dr.


Why can’t I call my branches whatever I want???

Why would you do this? If I ever need to re-create a branch I have to give the new URL to the testers?

Why? This is stupid.

1 Like

Branch names need to be unique for them to function properly, so we moved to unique IDs for branches to ensure uniqueness, but to also allow users to select whatever display name they would like for their branch.

Several users have provided the feedback that this is slowing down their development flows so its definitely on our radar. There may be an opportunity to allow users to specify a slug for their branch (to remain consistent in the URL) - but this required more work than was expected to implement, so we did not want to hold up the release of the new version control for that feature alone.


Its all good, I’m frustrated by the bugs too. We are definitely in a “if a tree falls in a forest, and no one is there to hear it…” type situation with many Editor bugs though. As we work on improving our internal QA processes, bug reports (especially for high priority & sensitive features like version control) are critical to addressing issues in the wild.

I can assure you, we did not invest a year in rebuilding version control to not solve previous pain points and to not resolve any bugs that may arise in a prompt manner.