Branching Strategies

Versioned applications support multiple branches at the same time. Choosing a consistent branching strategy helps teams work in parallel, review changes safely, and maintain a predictable release process.

Feature Branching

Feature branching is the most common pattern. Each piece of work lives on its own branch: a new feature, a configuration change, or a set of related updates.

How it works:

1. Create a branch from the current default version.
2. Build and test the feature on the branch.
3. When ready, publish the branch as a new version.
4. Set the new version as the default to make the feature live.
5. Delete the branch after publishing.

When to use it: Most teams use feature branching as their default pattern. It keeps the default version stable while work is in progress and gives each change a clear publish point.

Hotfix Branching

Hotfix branching isolates an emergency fix from in-progress feature work. The fix is created from the live version, published independently, and then merged back into any open feature branches.

See Hotfix Branching for step-by-step instructions.

When to use it: When a critical issue in the live application must be resolved before the next scheduled release.

Parallel Development

Parallel development uses multiple simultaneous branches so different teams or workstreams can progress independently.

How it works:

1. Create a branch for each workstream from the same base version.
2. Teams work on their branches independently.
3. Before publishing, merge one branch into the other to consolidate changes.
4. Resolve any conflicts in the merge workflow.
5. Publish the consolidated branch.

When to use it: When two or more workstreams must proceed simultaneously and cannot wait for one to publish before the other begins.

Important: The more branches diverge from a common base, the more conflicts are likely at merge time. Merge branches together regularly to reduce drift.

Branching From a Branch

Create a branch from an existing branch instead of a published version. This is useful when building a dependent piece of work on top of changes that have not been published yet.

When to use it: When work on Branch A is a prerequisite for work on Branch B, and Branch A has not been published. Create Branch B from Branch A, complete the work, then merge Branch B back into Branch A before publishing.

Note: If the source branch is updated after the new branch is created, merge the source branch into the new branch to pull in the latest changes. See Merging Branches.

Branch Naming Conventions

Branch names must follow the rules described in Creating Branches. In addition, consider adopting a naming pattern that communicates purpose:

• feature/payment-validation: a named feature
• hotfix/login-redirect: an emergency fix
• release/q3-updates: a release batch

Consistent naming makes it easier to identify the purpose of each branch at a glance.