Git Workflow

This document defines the Git branching strategy, commit conventions, and pull request process for the CPR frontend.

Repository

• Remote: https://github.com/RackApp-IT-Solutions/cpr-frontend
• Primary branch: master

Branch Naming Conventions

All work happens on short-lived branches created from master. Use the following prefixes:

Prefix	Use case	Example
feature/	New functionality or module	feature/patient-billing
bugfix/	Fix for a non-critical bug found during development	bugfix/insurance-pagination
hotfix/	Urgent fix for a production issue	hotfix/login-token-expiry
refactor/	Code restructuring with no behavior change	refactor/service-error-handling
chore/	Tooling, config, dependency updates	chore/upgrade-nuxt-4.3
docs/	Documentation only	docs/api-fetch-composable

Rules:

• Use lowercase and hyphens (no underscores or camelCase).
• Keep names short but descriptive.
• Always branch from the latest master.

git checkout master
git pull origin master
git checkout -b feature/surgery-schedule-filters

Commit Message Conventions

Use the following format:

<type>: <short description>

Types

Type	When to use
feat	A new feature
fix	A bug fix
refactor	Code change that neither fixes a bug nor adds a feature
chore	Build process, dependency updates, config
docs	Documentation changes
style	Formatting, whitespace (no logic change)
test	Adding or updating tests
perf	Performance improvement

Guidelines

• Start the description with a lowercase verb (e.g., add, fix, update, remove).
• Keep the first line under 72 characters.
• Use the imperative mood: "add filter" not "added filter" or "adds filter".
• Reference issue numbers when applicable.

Examples

feat: add surgery schedule filtering by doctor
fix: resolve pagination reset on insurance search
refactor: extract error handling into service base class
chore: upgrade @sentry/nuxt to 10.38

Pull Request Process

Before Opening a PR

1. Rebase your branch on the latest master:

   git fetch origin
   git rebase origin/master

2. Run code quality checks:

   npm run lint
   npm run format

3. Fix any lint or formatting errors before pushing.

4. Push your branch:

   git push -u origin feature/your-feature-name

Creating the PR

Open a pull request on GitHub targeting master. The PR should include:

• Title -- Same format as commit messages: <type>: <short description>
• Description -- What changed and why. Include:
  • Summary of changes (bullet points)
  • Screenshots for UI changes
  • Any migration steps or env variable changes
  • Related issue numbers

PR Template

## Summary
- Added/Updated/Fixed [what]
- [Why this change was needed]

## Changes
- [List of specific changes]

## Screenshots
[If applicable]

## Testing
- [ ] Tested locally with dev server
- [ ] Linting passes (`npm run lint`)
- [ ] Formatting passes (`npm run format`)
- [ ] No TypeScript errors

Code Review Requirements

• Every PR requires at least one approving review before merging.
• Reviewers should check for:
  • TypeScript type safety (the project uses strict: true)
  • Proper error handling with Sentry reporting in services
  • Consistent use of the composable pattern (loading/error/success refs)
  • No console.log left in code (production build strips them, but keep the codebase clean)
  • Component naming matches the file-based auto-import conventions
  • Sensitive data is never logged or exposed (this app handles patient medical records)

Merge Strategy

• Use squash and merge for feature and bugfix branches to keep master history clean.
• Use merge commit for hotfix branches to preserve the fix context.
• Delete the source branch after merging.

Post-Merge

After your PR is merged:

git checkout master
git pull origin master
git branch -d feature/your-feature-name