Your first PR

Mechanical conventions for a clean PR. Nothing here is enforced by a robot — these are the patterns the team actually uses, so matching them makes review smoother and your work easier to find later in git log.

Branch naming

Branches are named after the unit of work, not after the author. Three patterns cover almost everything:

Branch off main. Keep branches short-lived — open a draft PR even if the work isn’t done, so the team can see what’s in flight.

Two project prefixes are in active use in Jira:

• TUN- — main IBA backend project
• TNBUGS- — bug-tracking project
• TMA- — mobile app

If you’re not sure which to use, ask in the channel. The branch name just needs to match a real ticket the reviewer can open.

Commit messages

Free-form English, imperative mood. The first line is the title (under ~72 characters), then a blank line, then a body of one or more paragraphs explaining why the change is being made and what actually changed — at a level a teammate skimming git log in six months would understand without opening the diff.

A Jira ref at the start of the title is optional but encouraged:

TUN-1234 Suspend a flyer's currency when their licence expires

The currency engine was counting expired licences as valid because
the `validUntil` check used the licence's local timezone instead of
UTC. This commit moves the comparison to UTC and adds a regression
test for the boundary case where a licence expires at exactly 00:00
in the flyer's local zone.

The fix is purely on the read path; no DB migration needed.

A few patterns the team avoids:

• Empty PR template bodies. Filling in the template is the point of having one — see picking a template below.
• Co-Authored-By: Claude or other AI attribution trailers. Commits should look like the author’s own work.
• amend after pushing. Create a new commit instead. Force-pushes to shared branches break reviewers’ ability to follow incremental changes.

Picking a PR template

Heads-up — GitHub doesn’t show a template picker for PRs. The chooser dropdown you may remember from other repos only exists when you open an issue. For PRs, the default template at .github/PULL_REQUEST_TEMPLATE.md is silently applied no matter what.

There are four templates available:

To use one of the three specialty templates you have to either:

1. Edit the compare URL to add ?template=feature.md (or bugfix.md, hotfix.md) before the form is submitted, OR
2. Copy-paste the template body from .github/PULL_REQUEST_TEMPLATE/ over the default — less elegant, more reliable.

See Infra → GitHub → PR templates for the full URL pattern, links to each template, and the GitHub-side context.

Opening the PR

1. Push the branch: git push -u origin <your-branch>. The pre-push hook may flag missing docs — address those first.
2. Open the PR against main. Default reviewer is the tech lead; the team uses GitHub’s “Reviewers” suggestion which usually picks the right people based on which files changed.
3. Pick a template as above. Fill it in. Empty PR descriptions get asked-back.
4. Apply labels to control downstream automation:
   • deploy-preview — spin up a live preview environment (details)
   • deploy-preview-with-db — preview + an isolated DB cloned from production S3 backup
   • Triage labels (Urgent / High / Medium / Low) for the team’s own prioritisation
5. Wait for CI. Three checks run on every PR: docs-required (the docs-update flag), jira-link (warns if the title has no Jira ref), and the Cloudflare Pages docs build. All three must be green to merge.
6. Address review. Push more commits to the same branch — do not force-push. Re-request review when the comments are addressed.
7. Merge. The team uses squash merge for everything. GitHub appends (#NNN) to the squashed commit title automatically.

What’s next

If you applied a deploy-preview label, read Deploy previews for what you’ll see happen in the next 5–10 minutes.