A branching strategy is a set of rules that development teams use to manage the process of building, merging, and deploying configurations with the help of a version control system, like Unqork’s Application Versioning. It defines how Creators interact with a shared configuration base.
Branching strategies are essential for modern software development. They let Creators maintain organized projects and avoid errors when multiple Creators are working simultaneously on the same application.
Branching Strategies
When you work in a team and you want to implement branches, you need to agree on a strategy for how to use branches in a project. Projects can be different, so you might need to implement different strategies.
The following branch strategies are examples you can adopt for building applications. The best strategy for your team depends on your application and goals. Click the following tabs to explore more.
Trunk-Based Development
This approach has some considerations. For example, multiple developers cannot edit the same module concurrently because Unqork does not let multiple Creators simultaneously edit the same module in the same branch. The main benefit of this strategy lets you take advantage of Application Versioning without having to deal with merging. It’s also the closest form of development at Unqork when Application Versioning is not enabled. This strategy might be suited for large teams and complex applications, as long as there is no need for concurrent development.
Feature Branching
In this approach, new features are developed on separate branches originating from the latest version. They should follow a naming convention, like feature name, ticket number, and so on. These feature branches should only be published into a new version after completion and thorough testing, ensuring the latest version remains a reliable source.
This approach offers several benefits, including parallel development, enhanced collaboration, and isolated workflows, which accelerate development cycles and facilitate teamwork. There are some considerations to keep in mind, like module editing conflicts when multiple developers work on the same module. That way, developers can keep features small for managing merge complexity and maintaining the overhead with consistent merging to keep branches updated.
Release Branching
In this approach, each Production release is assigned a dedicated branch, serving as the integration point for all features ready for that release. Developers can create and test features in individual branches, then merge them into the release branch. Releases are regularly rebased from the latest stable application version to incorporate all bug fixes and improvements.
This strategy requires the Branches of Branches feature. This feature is scheduled for the 7.30 Unqork release. View the release calendar and release notes for information on Branches of Branches availability.
This approach offers benefits that include independent feature deployment and grouping, enhanced developer collaboration with releases, and facilitation of parallel releases, like hotfixes and new features. Developers cannot edit the same module in the same branch simultaneously. This approach is similar to the other models and is more process-intensive than others because branching and merging happen frequently.
Branch Nesting
Branch Nesting (branches of branches) is an evolution in version control systems, significantly impacting how development teams implement and manage their strategies. Traditionally, branches represent individual features or fixes. With nesting, teams can create sub-branches that group multiple features under a single release branch. This advanced capability of creating branches in branches makes it easier to organize, stabilize, and deliver releases efficiently.
Discover how to create branches of branches in our How to: Create a Branch From a Branch article.
General Strategies
This feature enhances all three primary strategies discussed:
Trunk-Based Development
Trunk-Based Development emphasizes maintaining a single main branch as the central integration point for all code. While this model discourages long-lived feature branches, branch nesting offers flexibility by allowing short-lived release sub-branches when needed.
These sub-branches provide a temporary workspace to test grouped changes before merging them into the trunk. By following a policy of keeping release sub-branches temporary and tightly scoped, teams can balance stability on the main branch with controlled release coordination.
Feature Branching
Feature Branching is an effective strategy for parallel development, enabling multiple teams to work on different features simultaneously. Instead of focusing on sub-features of a single feature, the Branch Nesting strategy lets teams group multiple feature branches into a shared release branch.
This grouping lets teams validate integration between several features and ensure everything works as part of the upcoming release. You can also resolve conflicts in the release branch to reduce repetitive merges and increase delivery confidence.
Release Branching
The Release Branching strategy plays a central role in enabling stable, predictable deployments. With the nesting capability, development teams can create release sub-branches that consolidate multiple features targeted for the same release cycle. Instead of applying changes directly to the release branch, developers can branch new, temporary sub-branches from it to make last-minute fixes or adjustments.
Each of these sub-branches undergoes focused testing before being merged, ensuring the overall release remains stable and ready for Production deployment.
Best Practices
The following best practices can significantly reduce conflicts, streamline integrations, and ensure the stability of your configuration:
Naming Conventions: Adopt a consistent naming pattern to keep release branches and their sub-branches organized. For example,
featureX-subA.Merge Order: Always merge sub-branches back into their release branch before merging the release into the main branch.
Version Awareness: Track dependencies between release sub-branches to avoid overwriting validated changes.
Testing Discipline: Test all release sub-branches thoroughly before merging to ensure a stable integrated release.
Avoiding Pitfalls
To ensure a smooth development process, be mindful of these common pitfalls:
Excessive Branching: Avoid creating unnecessary sub-branches under releases. Only create sub-branches if a change needs isolated testing.
Untracked Dependencies: Avoid making changes to shared modules or libraries across all sub-branches without proper coordination to prevent integration issues.
Delayed Merges: Regularly synchronize release sub-branches to ensure they are aligned, minimizing complex merge conflicts before the final release merge.