Introduction

When using VB Studio to build personalizations, you also need a reliable way to package and deploy those changes across environments. To support multiple implementers, different project phases, and a full build–test–go-live lifecycle, it’s important to establish a Git branching strategy where each branch serves a clear and distinct role.

A good VB Studio Git strategy for Fusion Cloud should let you:

  • build new work continuously,
  • stabilize a release without blocking future work,
  • promote only tested code forward,
  • and patch production safely without reopening everything else.

Types of Branch

We propose the following types of branches to support the development lifecycle:

Main Branch

The main branch should be used to contain changes that are ready for Production deployment.

The changes that are merged to main should be fully tested, both in isolation and as part of integrated testing.

Feature Branch

A feature branch is used for the development of personalizations within a defined scope, such as a specific module, sprint, or project phase. It captures changes that can be developed, tested, and refined without impacting the stability of other branches.

Typically, a feature branch is created from the main branch and is owned by an individual developer or a small team. It allows focused work on a particular set of requirements—whether that’s delivering functionality for a sprint or implementing changes for a specific module—while supporting parallel development across the wider team.

Once the personalization work is complete and validated, the feature branch is merged back into the main branch, ensuring that changes are incorporated in a controlled and traceable way.

Once a feature branch has been completed and merged into the main branch, it should be deleted to keep the repository clean and avoid confusion. If further work is required on the same module in a later phase, a new feature branch should be created from the main branch rather than reusing the old one. This ensures a clean starting point and maintains a clear, traceable history of changes.

Integration Branch

An integration branch is used to combine multiple feature branches so they can be packaged and deployed together for testing. It provides a controlled environment where related changes are validated as a group, helping to identify integration issues before they are promoted further in the lifecycle.

Some teams need a branch between “feature” and “main.”

Use this branch when:

  • multiple features depend on each other,
  • a team wants to validate a bundle of changes,
  • you are preparing a demo or milestone test drop,
  • or you need shared QA without destabilizing the main branch.

Do not use this branch as:

  • a long-term substitute for release management,
  • or a dumping ground for unfinished work.

Once integration testing is complete, the integration branch should be deleted to keep the repository clean and avoid carrying forward outdated combinations of features. If further testing is required, a new integration branch can be created using the latest versions of the relevant feature branches, ensuring a fresh and accurate baseline for the next cycle.

Release Branch

A release branch is used to isolate personalizations that are to be deployed to Production.

The release branch should be created from the main branch at the point at which the code is deemed to be ready for production. This effectively freezes the code in this branch.

The branch can be packaged and deployed for final testing.

The only type of changes that should be allowed in this branch are:

  • release blockers,
  • regressions,
  • critical bugs,
  • approved compliance or security fixes.

If changes are made in this branch, ensure that the same change is made in the main branch, to ensure it has all the changes that will be in production.

Hot-fixes required in production can be made on the release branch in order to be able to deploy to production in a timely manner, but these should be backported to the main branch, and subsequently to any feature or local developer branches.

Summary of Branch Types

Branching Lifecycle

Create a new Branch from a Parent Branch

In Oracle Visual Builder Studio (VB Studio), you can create a new branch from a parent branch by first opening your project and navigating to the Git tab. From the list of available branches, select the parent branch (such as main or develop) that you want to branch from. After selecting the parent branch, click the Refs->Create Branch, enter a name for the new branch (for example, feature1), and confirm that the selected parent branch is correct. Finally, click Create to generate the new branch. The new branch will now contain all the latest code and history from the parent branch and can be used for independent development or bug fixes.

Branch Protection

Branch Protection allows a Project Owner to control how code is merged into a branch. In the Project Administration -> Branch Protection UI they can set the protection level to “Requires Review”. This means that code can only be merged into the branch via a merge request which also requires approval.

Setting this level of protection is recommended for main, Feature and Release branches, and optional for Integration branches.

Summary

In this blog we have discussed the best practice for setting up branch structures to support the Redwood personalization development lifecycle.