Branching is like making a separate copy of your work so you can try out new things without messing up what you've already done. Branching allows multiple builders or teams to work on different features simultaneously without interfering with each other.

Let's say you have an app that's like a digital cookbook. You want to add a new feature, like a shopping list. Instead of adding it directly to your main app and possibly causing issues, you create a branch to work on this new feature. Once it's perfect, you can bring it back into the main app.

Creating a branch here doesn't create one on GitHub. Branches stay and are managed solely within our platform. However, to manage custom code in Github, check out the tutorial here.

This feature is only available for teams and enterprise users.

Working with Branching

Before you create and merge a branch, it is essential to understand the general workflow. Here's what it looks like:

First, create a new branch from the 'main' branch. After making your changes and finalizing the feature, proceed to merge this new branch back into the main branch. If there are any conflicts, you must resolve them, and you'll able to merge the new branch into the main branch successfully.

Few things to note here:

  • At the moment, we support merging only back into the main branch.

  • During an ongoing merge, only the user who initiated the merge can access both the main project and the branch.

  • Changes that don't conflict are resolved automatically.

  • Undo/redo doesn't work with merges, but a merge can be aborted if you want to start over.

  • If you leave the project during the merging and come back, the progress you have made on the merge will be preserved.

Create and merge branch

Let's see how to create, merge branches, and resolve conflicts, if any, with a practical example. Here's how it goes:

  1. First, click the merge icon (from the Toolbar) > click a button inside the branch name > select Create New Branch. Provide the appropriate branch name (e.g., 'feature1', 'AddShoppingCart,' 'AddLogin,' etc. ), and then click Create Branch. This will create and display the new branch in a new browser tab.

Tip: You can also create a new branch from any existing branch.

  1. Make some changes in the new branch, and from the same menu, select the Merge [feature_branch] into [main]. You could also select the Rebase [feature_branch] into [main], which rewrites the feature branch's history to appear as if it was built directly on top of the latest main branch.

  • It's important to note that if you're working in a collaborative setting where maintaining an accurate historical record is important, it's safer to simply use the Merge option.

  • Know more about Merge vs Rebase here.

  1. Now, you'll see a screen that will display if there are any conflicts. If not, you can simply go ahead and click Merge Branch.

  2. While you make changes in the new branch, if there is any change in the 'main' branch for the same page at the same location, you'll likely get conflicts, which will be displayed here.

  3. To resolve the conflicts, click on the See All Changes button, and you'll see one more screen that allows you to see and resolve conflicts in the visual editor. To get back to the previous screen, click the Review Conflicts button at top right side.

  4. When you collapse the Review Changes section, you'll see the Accepted Changes section. This section shows the final changes, and from here, you can click Resolve Conflicts.

    1. This will open the split screen view displaying changes from the new branch and main branch. Here, you have the option to accept changes from the main, branch or resolve manually.

      For certain conflicts (apart from widgets), such as those involving variables and API configurations, you'll get options to accept the change or resolve it manually by clicking the Resolve Conflicts button.

      Also, you'll see a View Configuration option. Enabling this option opens the split screen view displaying changes from the new branch, allowing you to easily identify what has changed.

    2. If you choose to resolve manually, you can directly make changes in the Accepted Changes section and click Save. Note that if you cancel a manual resolution, you can choose to either keep or discard the changes you have made since starting the manual resolution.

    3. In the case where we don't show something in the split screen UI that you want to handle during a merge, you can click the Edit Project button and edit the project as you would normally. Tip: Run mode, Preview mode, and downloading code works in this mode.

    4. After all the conflicts have been resolved, go back to the previous screen by clicking on the Review Conflicts button and then click Merge Branch.

  5. Now, switch to the 'main' branch and verify if the changes are added there.

  6. As best practice, branches should be kept short-lived (to avoid integration nightmares). That means you should close (delete) the branch after it merges into the 'main'. To do so, you can switch to a branch you want to delete, and hit the Close button.

Merge vs Rebase

The Merge option combines changes from different branches with a new commit, keeping a branched history. It's easier and more suitable for teams with simultaneous updates.

The Rebase option applies branch commits in a linear history onto the main branch, which is more complex but creates a cleaner timeline. Ideal for individual work and active main branches.

Let's understand the difference in detail with a scenario; Imagine you are working on a feature in your own branch while your colleague is making updates to the main branch.

Before Merging/Rebasing:

Your feature branch has two commits: Commit 1 and Commit 3 (which are your changes), and Commit 2 (made by a colleague in the main branch).

After Merging:

It creates a new merge commit. This merge commit ties together the histories of the feature and main branches. The result is a divergent history that converges with the merge commit, preserving the sequence of commits as they were originally made.

After Rebasing:

Your commits (Commit 1 and Commit 3) are replayed on top of Commit 2, which is the latest in the main branch. This makes it look like your changes were made after your colleague's changes, creating a clean, linear history.

Important: It's essential to be cautious with rebasing, as it can rewrite commit history and potentially cause confusion for other collaborators. Merging is a safer option when working with shared branches in collaborative projects.

Last Updated Date: April 11, 2024

Last updated