Skip to content

๐Ÿ”€ Pull Requests โ€‹

๐ŸŒฟ Branch Naming โ€‹

Use descriptive branch names with a prefix:

PrefixUse
๐Ÿ†• feat/New feature
๐Ÿ› fix/Bug fix
๐Ÿ“ docs/Documentation changes
โ™ป๏ธ refactor/Code refactoring
๐Ÿงช test/Adding or updating tests
๐Ÿ”ง chore/Maintenance, dependency updates

Examples: feat/table-reservations, fix/order-total-calculation, docs/api-reference

๐Ÿ“ Conventional Commits โ€‹

Use Conventional Commits for commit messages:

feat: add table reservation system
fix: correct order total calculation with coupons
docs: add API reference for loyalty endpoints
refactor: extract payment processing into service
test: add integration tests for coupon validation
chore: update Prisma to v5.22

Include a scope when helpful:

feat(reservations): add availability check endpoint
fix(payments): handle Stripe webhook signature verification

โœ… PR Checklist โ€‹

Before submitting a pull request, ensure:

  • [ ] ๐Ÿ”จ Code compiles (npx tsc --noEmit)
  • [ ] ๐Ÿงฉ Unit tests pass (npm run test:unit)
  • [ ] ๐Ÿ”— Integration tests pass (npm run test:integration)
  • [ ] ๐Ÿงช New features have tests
  • [ ] ๐Ÿ“š API changes are documented
  • [ ] ๐Ÿšซ No console.log statements left in
  • [ ] ๐Ÿ“‹ Environment variables are documented in .env.example

๐Ÿ‘€ Review Process โ€‹

  1. ๐Ÿ“ค Open a PR against main
  2. ๐Ÿค– CI pipeline runs automatically
  3. โœ… At least one approval is required
  4. ๐ŸŸข All CI checks must pass
  5. ๐Ÿ”€ Merge with squash or rebase (keep a clean history)

๐Ÿ“„ What to Include in a PR Description โ€‹

  • ๐Ÿ“Œ What โ€” Brief description of the change
  • ๐Ÿ’ก Why โ€” Motivation or issue being solved
  • ๐Ÿ”ง How โ€” Key implementation decisions
  • ๐Ÿงช Testing โ€” How the change was tested
  • ๐Ÿ“ธ Screenshots โ€” For UI changes

๐Ÿ”€ Squash Merge Convention โ€‹

We use squash merges to keep main history clean. Because of this:

  • ๐Ÿ“ PR title must be a conventional commit โ€” It becomes the squash commit message (e.g., feat: add table reservation system)
  • ๐Ÿ“‹ PR description becomes the commit body โ€” Write it as a meaningful commit description, not just a review checklist
  • ๐Ÿท๏ธ Include a scope in the title when helpful (e.g., fix(payments): handle webhook retries)

Example PR title and body that produce a clean squash commit:

Title: feat(reservations): add availability check with party size validation

Body:
Add real-time table availability checking that considers party size,
existing reservations, and restaurant hours. Includes admin UI for
managing table configurations per location.

- Add GET /api/reservations/availability endpoint
- Add table management UI in admin panel
- Add integration tests for availability logic