Have you ever encountered coordination issues while working with other Bubble.io developers on the same application?

Does it happen sometimes that when someone makes changes live, they replace your previous changes which they should not have?

Have you ever felt that if only another developer told me that he/she was changing this, the whole mess could have been avoided?

Have you ever thought, "How should I coordinate with everyone every time working on the same app so that we don't mess things up because of lack of coordination?"

Well if you have gone through this, here I am explaining my best practices which I developed working with other top-notch bubble.io developers.

Before going towards the solution, let's understand Bubble's version control.

Key highlights about Bubble's version control

• Bubble's version control system lets you divide the development of your project into independent parts so that you and other editors with access to the project can iterate on one part of the app without impacting other parts.

• Bubble's version control helps you simultaneously progress multiple streams of work and stay on top of the changes made as each goes from development to testing to deployment.

• Version control is available when your application is on the Growth or Higher bubble.io plan

• A branch is an independent iteration of your application that can be developed in isolation. The branch is not the development or live environment, it is part of the environment.

• Base Branch: It is a branch into which you want to merge changes.

• Source Branch: It refers to the branch that is the source of changes that you want to merge into the base branch

• Merge/Merging: The process of integrating changes from the source branch into the base branch

• Sync: To sync two branches is to merge them to bring changes in Live or Main into the base branch

• Everything except deploying is a "Pull" rather than a "Push" - the distinction between "Sync" and "Merge" is that "Sync" implies you are pulling changes because you are behind your Main / Live branches. "Merge" implies you are pulling new development changes that will put you ahead of your Main / Live branches. It is always "Pull" until you deploy. ( - Sam Morgan)

• A child branch of the 'Main Branch' can also be a Parent branch to its child branch

  

My Thumb Rules while working with other Developers

Every developer who is working on the same application has to follow this to get successful results.

• No Developer will ever work in the Main Branch.

• Only 1 developer will work in 1 branch. More than 1 developer will not work in the same branch. Period.

• If 2 developers have to work in the same branch, create 2 child branches (child-branch-1 and child-branch-2) from that branch.

• If 2 developers still have to work in the same branch, only 1 developer will work and the other developer will just guide/instruct/help via Google Meet/Teams/Skype.

• 1 Branch will be used for 1 feature development. Once it is developed, merge the child branch with the parent branch. If the parent branch is not the main branch, then merge that parent branch with its parent branch until the parent branch is the main branch.

• Before starting the merge, Always check whether your branch and Main branch are in sync with Live or not. If Not, first sync your main branch with Live. Once your Main branch is in sync with Live, Sync your branch's parent branch (only if the Parent branch is not the Main Branch) with Live. After all the parent branches are in sync with live, then sync your branch with live.

• Create one common space (using Slack channel/ Discord / Google Spaces etc.) in which all the stakeholders (other than the client) including but not limited to Bubble.io developers who are working on that application are part of. Whenever one developer merges his/her branch with the main branch, that developer will update about it in that common space and other developers will immediately sync their parent branch(if it's not the Main Branch) and then own the branch with the live branch.

• Whenever the developer starts merging, the developer will check in to review changes if there is anything on which he/she hasn't worked but showing changes.

  

• After Reviewing the changes, there will be a resolved conflict. The developer only selects the options between the source branch and the base branch for which he/she is 100% confident. If there is 0.000001% doubt about any conflict, the developer must communicate with other relevant developers (via writing in a common space, having one-on-one or team meetings)

Things I highly recommend along with these practices based on my experience

• Communicate and coordinate with other developers from time to time (I recommend weekly at least) about what you all are working upon. Discuss your processes, something new you learned about this app while working on it, something challenging you have completed, how you got it done and most importantly what challenges you faced from the existing structure of the application.

• Don't scold/disrespect someone because someone did not do something your way but at the same time, don't shy away from discussing the best approach to achieve the desired results.

• Document the changes (bullet points/highlights) you merged with the main branch (especially when you are in the process of checking 'Review Changes'). Whenever something is messed up, this will be a lifesaver. Believe me!)
  [ Reference article for documentation: https://anishgandhi.com/bubble-documentation ]

• These best practices must be implemented from top to bottom. You can't convince developer all the time but You can lead the developer by example and others can be inspired.

These are things my experiences taught me, Feel free to share anything you would like to add in the comment section. You can connect with me here on LinkedIn.