Development Process

### Branching Strategy

• Begin all local development by pulling the latest MAIN branch.
• Create a new branch from main using a naming convention that reflects the purpose of the branch, prefixed with initials for easy identification. Our convention is in the PR template for the repos. It is <initials>_<short_description>_<story_number>. Example: jck_add_pr_template_538104.
• Keep branches short-lived, ideally merging them back into main within a few days.

### Commit Guidelines

• Use structured commit messages prefixed with the relevant User Story or Bug ID to ensure automatic linking in Azure Boards (e.g., #12345 – Created custom class component for the text input to allow max length to be universally governed).
• Keep commits small and focused to maintain a clear development history.

### Syncing with main

• Before pushing changes to remote, ensure your branch is up to date with main by performing a rebase:  

  git pull --rebase origin main

• Resolve any merge conflicts locally, commit changes, rebase again, and then push changes.

## Pull Request Best Practices

### Creating a Pull Request

• Ensure your PR meets the following criteria before submission:
  • A User Story or Bug is linked to the PR (tracked in Azure Boards).
  • A screenshot of any UI changes is attached.
  • PR title follows the format: [Team Name] | [User Story #] | [User Story Title].
  • Solution builds and runs locally without errors.
  • Unit tests are created and meet code coverage requirements.
  • All unit tests pass.
  • Linting issues are resolved.
  • Latest main branch changes are merged, and conflicts are resolved.
  • Updates are documented in the User Story for QA handoff.
  • Changes have been demonstrated to the QA team.

### Responsibilities of PR Authors

• Ensure PRs are small, incremental, and mergeable at all times.
• Actively seek reviews from peers and promptly address feedback.
• Follow up to ensure PRs are reviewed and merged in a timely manner.

## Code Review Expectations

### Reviewer Responsibilities

• Conduct thorough reviews of every change in the PR.
• Verify that changes align with the acceptance criteria of the linked User Story or Bug.
• Ensure all checklist items in the PR template are met.
• Use “nit” prefix for minor style-related suggestions to avoid derailing the PR.
• At their discretion, reviewers may pull and run the code locally for complex changes, but testing is primarily handled via build pipelines, automation tests, and QA validation.

## Merging Criteria

• PRs should only be merged once all criteria are met and at least one approved review is obtained.
• Merge small, tested, and reviewed PRs frequently to avoid large, complex changes.
• Use fast-forward merges where possible to maintain a linear history.