This guide applies to every repository in the organization. For the full project canvas (README template, Definition of Done, ADRs...), see project-guidelines.
edpage-hq projects follow GitHub Flow: master is the only long-lived
branch and is always deployable. There's no develop, release, or
long-lived environment branch.
- Branch from
master(see naming convention below). - Keep branches short-lived — open a PR as soon as there's something reviewable rather than letting a branch accumulate a large diff.
- Merge back into
mastervia PR once CI is green and approved. - Hotfixes follow the exact same path — branch from
master, PR, merge. There's no separate hotfix process; urgency is handled through review priority, not by skipping CI or review. - Delete the branch once merged.
feature/<short-name>— new featurefix/<short-name>— bug fixchore/<short-name>— technical task with no functional impact
Short, explicit, type + description:
feat: add login screen
fix: correct pagination on the orders list
chore: bump dependencies
JS/TS dependencies are managed with pnpm — do not use npm install or yarn add, and don't commit package-lock.json/yarn.lock.
- PHP (Laravel): Pint must pass before merge
- JS/TS (AdonisJS, Vue, React): ESLint + Prettier must pass before merge
- Dart (Flutter):
flutter analyzeanddart formatmust pass before merge
- Branch from
masterfollowing the naming convention above. - Fill in the PR template — do not delete sections, mark items not applicable as N/A.
- Make sure CI is green before requesting a review.
- At least one approval is required before merging (see branch protection rules).
- Squash-merge once approved, unless the repo's README says otherwise.
Use the issue templates — they ask for the information reviewers need to act quickly. Issues without enough context to reproduce or evaluate may be closed and asked to use the template.