Branching Strategy

Master Branch

The default branch of this project is master.

This branch can also be thought of as the latest branch in that it contains all the latest changes. It can also be through of as the development branch in that it should be an exact match for what is currently deployed to a development and/or test environment where applicable. All branches should be based off of this branch and should be merged into this branch when a PR has been approved.

The contents of this branch should be continuously deployed to a development and/or test environment where applicable.

Releases are created from this branch by creating a tag. The tag should be in the format v${MAJOR}.${MINOR}.${PATH} following SemVer. The tagged release should be deployed to a production environment where applicable.

Feature Branches

A feature branch is a branch where one or more developers are actively developing a single change. This change can be a new feature/functionality, bug fix/patch, documentation update, or maintenance task.

A feature branch must be based off of the Master Branch and must be merged into the Master Branch when complete. Changes to the Master Branch should be integrated daily.

A feature branch can be deployed to a development environment where applicable.

Feature Branch Naming

When creating a feature branch, it must be named in a specific way for GitHub Actions to handle it correctly. The naming format is ${PREFIX}/${DESCRIPTION_OF_CHANGE}.

Prefixes

bugfix | fix | hotfix:

The branch contains a fix for a big.

feature | feat:

The branch contains a new feature or enhancement to an existing feature.

docs | documentation:

The branch only contains updates to documentation.

chore | maintain | maint | maintenance:

The branch does not contain changes to the project itself to is aimed at maintaining the repo, CI/CD, or testing infrastructure. (e.g. README, GitHub action, integration test infrastructure)

release:

Reserved for maintainers to prepare for the release of a new version.