Skip to main content

Branching Model

Rizing development uses a release branching model, where Pull Requests are the main trigger for actions (like deployments). Additionally, Pull Requests serve as a gatekeeper to ensure that code meets QA/QC standards and all functional acceptance criteria is met. The best time to find bugs, is before that code makes it into your stable code base.

Release model

Release model

See Development Workflow for more details.

Main Branch​

The main branch...

  1. Represents the latest released code.
  2. Is never directly pushed to (changes are only applied via PRs)
  3. PR commits should always be "squashed"

Release Branches​

Release branches...

  1. Should be created off of main branch
  2. Path releases should be created off of the parent release branch (ex: 1.0.0 --> 1.0.1)
  3. Release branches are never deleted
  4. Release branches should only be updated via PRs
  5. Should be named with the pattern release/[product]/[version]

    ex: release/omni/v1.0.0

  6. PR commits should always be "squashed"

Feature & Bug Branches​

Feature and bug branches...

  1. Should be named with the pattern [product]/[user]/*

    ex: omni/russell.green/123-my-feature-name

  2. Branches should be deleted after the respective PR has been merged

References​