Master branch

The master branch contains the public and stable, currently released version of the plugin. At the end of a release cycle, release branches are merged into the master branch. The master branch should generally not be committed to, except by the developer in charge of releasing the plugin.

NOTE: if you need to test something against the currently released version of the plugin, a simple way to switch to that version is by checking out the master branch. Just be sure to switch back to your working branch before you make any commits!

Top ↑

Release branches

We organize our releases on release branches by team. Release branches follow this naming scheme: release/<T><Y>.<N>[.<H>], where:

  • T = team initial
  • Y = 2 digit year
  • N = release name (thematic, alphabetical name)
  • H = hotfix number

An example release from the 2nd release from Blue Team in 2021 would be: release/B21.bagel and a hotifx for that release would be: release/B21.bagel.1.

Top ↑

Ticket branches

NOTE: The following instructions are for internal use only, if you’re sending a pull request, it’ll already be in its own branch.

The naming convention for new branches should be as such

<feature|fix>/<ticket number>-<brief-description>

For example:

  • feature/TEC-24343-activation-page
  • fix/TEC-28363-list-view-eod-cutoff
  • spotfix/TEC-123-very-minor-text-change

Top ↑

Types of Pull Requests

Top ↑


Top ↑


When working on features that require multiple devs, multiple sprints, or parts built in chunks, we consider this a major feature. Major features require “Bucket branches”–specifically, branches named bucket/feature-name. These bucket branches should be decided upon by the team, as all PRs related to that feature will be pull requested into that bucket branch.

Major features are segregated into bucket branches to allow for focused QA effort before being merged into a release branch, as major features carry the most risk of being delayed.

Top ↑


Minor features can be developed using branches named feature/TICKET-name-of-feature and pull requested directly into release branches.

Top ↑


Fixes can be developed using branches named fix/TICKET-name-of-fix and pull requested directly into release branches.

Top ↑


Tweaks–or small changes to functionality with low impact–can be developed using branches named feature/TICKET-name-of-fix and pull requested directly into release branches.