Guidelines

[!IMPORTANT] Separate commits should be made for any CMS changes requiring a migration. E.g. you make a change that requires a migration. First commit the change, then commit the migration. There should be no commits in between.

General Rules

• Atomic Commits: Each commit should represent a single, specific change, to the best of your ability.
• Message Clarity: Ensure commit messages clearly state what the change is.
• Message Length: 12-72 characters
• Body Length: Not enforced
• Scope: Use lowercase, concise scopes if you want to specify a particular section (e.g., feat(nav): add dropdown menu).

Example Usage

• Adding a New Page: feat: add a contact page with form
• Changing Colors on Buttons for Consistency: ui: update primary button color across site
• Fixing Broken Link: fix: correct link in footer to redirect to new policy page
• Improving Page Load Speed: perf: compress splash images to improve load time
• Making Images More Accessible: a11y: add captions to staff photos
• Updating Privacy Policy: legal: update privacy policy to reflect data protection laws

Husky

These commit guidelines are remotely enforced and deployment will be blocked if conventions are not adhered to.

To prevent "bad" commit messages from reaching the remote server in the first place, we use Husky to run commitlint on every commit attempt. Husky is already installed locally as a dev dependency when you clone this repo.

You do not need to take any action here, but be aware of what is going on here and do not modify anything in /.husky/.