Branches

Branch names must either include a Jira ticket number or use an allowed prefix. This is enforced by the pr-checks.yml GitHub Action — PRs with invalid branch names will be blocked.

Naming Convention

Ticket branches

Use the branch name suggested by Jira when creating a branch from a ticket.

<PROJECT>-XXXX-short-description

Where <PROJECT> is a 2-4 letter Jira project key (optionally followed by a digit), e.g. APY, AB, APY1.

Examples:

• APY-1686-installer-app-documentation
• APY-1234-fix-login-screen-crash
• APY-5678-add-solar-battery-support

Non-ticket branches

For work that doesn't have a Jira ticket, use one of these prefixes:

Prefix	Use for
chore/	Maintenance, dependency updates, cleanup
docs/	Documentation changes
config/	CI, build config, tooling changes
e2e/	E2E test changes
supernova/	Automated design token updates

Examples:

• chore/update-dependencies
• docs/update-branch-naming
• config/pr-checks-and-template
• e2e/add-signup-tests
• supernova/colour-tokens

WARNING

Non-ticket branches are automatically labelled builds_disabled — they won't trigger PR builds or post to Jira.

Requirements

Requirement	Details
Format	<PROJECT>-XXXX-description or prefix/description
Case	Lowercase preferred
Separator	Hyphens within the description, / after prefix

What We Don't Use

We don't use the traditional feature/, bugfix/, hotfix/ prefix convention. The Jira ticket number or category prefix provides sufficient context.

Why This Matters

Now that we're moving away from the dev client, QA can no longer just find and test a branch directly. Without a ticket number in the branch name, there's no way to link the PR back to a Jira ticket — no build gets posted to the ticket, and QA won't know how to test the changes before they're merged. The ticket number is what connects the code change to the testing workflow.

The PR workflow uses the atlassian/gajira-find-issue-key action to extract the ticket number from the branch name. When found, it:

1. Posts build links directly to the Jira ticket
2. Enables traceability between code changes and tickets
3. Helps QA find the correct builds for testing

Non-ticket branches (chore/, docs/, etc.) skip this entirely — they don't need QA testing, so builds are disabled automatically.

See GitHub Actions for more details on the PR workflow.