Branches and commits

​

Branches

​

Working across repositories

• Pull dev in the repository you are about to change before you start.
• A feature that spans repositories needs one branch per repository. There is no shared commit.
• Deploy order matters when a change spans the API and a client. Ship the backend first when the client depends on a new field or endpoint. Keep the API backward compatible for at least one mobile release, because trainees do not update their app on your schedule. See Release checklist.
• Dependabot opens weekly pull requests against dev in the web repository. Major version updates are ignored by its config.

​

Commit messages

type(optional scope): subject

optional body

​

Rules

​

Examples

feat(clients): filter the trainee list by assigned coach
fix(whatsapp): reject a webhook with a bad token
refactor(forms): extract the conditions engine
chore(ci): pin the pnpm version in the mobile workflow

​

Other rules

• Never add an AI attribution trailer such as Co-Authored-By for an assistant. This rule is written into the coding standards of all three repositories.
• The backend bans the em dash character (U+2014) in source, JSON, Markdown and YAML. A commit that adds one fails ESLint. Write the subject with plain punctuation.
• Do not bypass hooks with --no-verify. If a hook is wrong, fix the hook in a chore(ci) commit.

​

Pull requests

• Target dev.
• CI must be green. See CI and Git hooks for what runs.
• Mention any database migration in the description, with its folder name, and say whether it has been applied to the shared database. See Database migrations.
• Mention any new native module in a mobile pull request. It changes how over-the-air updates must be handled. See OTA updates.