Branches in a Trunk strategy

A Trunk branching strategy commonly has the following branches.

feature branch

You develop features or create a hotfix in a feature branch. To create a feature branch, you branch off of the main branch. Developers iterate, commit, and test code in a feature branch. When a feature is complete, the developer promotes the feature. There are only two paths forward from a feature branch:

• Merge into the sandbox branch

• Create a merge request into the main branch

Naming convention:	feature/<story number>_<developer initials>_<descriptor>
Naming convention example:	feature/123456_MS_Implement_Feature_A

sandbox branch

This branch is a non-standard trunk branch, but it is useful for CI/CD pipeline development. The sandbox branch is primarily used for the following purposes:

• Perform a full deployment to the sandbox environment by using the CI/CD pipelines

• Develop and test a pipeline before submitting merge requests for full testing in a lower environment, such as development or testing.

Sandbox branches are temporary in nature and are intended to be short-lived. They should be deleted after the specific testing is complete.

Naming convention:	sandbox/<story number>_<developer initials>_<descriptor>
Naming convention example:	sandbox/123456_MS_Test_Pipeline_Deploy

main branch

The main branch always represents the code that is running in production. Code is branched from main, developed, and then merged back to main. Deployments from main could target any environment. To protect against deletion, enable branch protection for the main branch.

Naming convention:

main

hotfix branch

There is no dedicated hotfix branch in a trunk-based workflow. Hotfixes use feature branches.