Commit Standards
This document outlines the best practices for commit messages, branch naming conventions, and automated commit linting in our development workflow. Following these guidelines ensures consistency, maintainability, and better collaboration across the team. We are using conventional commits.
Commit message standards
Format
type(JIRA-ID): short description
type represents the purpose of the commit.
JIRA-ID is the associated Jira ticket (if applicable).
short description is a concise summary of the change.
Allowed commit types
| Type | Purpose |
|---|---|
| feat | A new feature |
| fix | A bug fix |
| chore | Maintenance work (e.g., refactoring, minor updates) |
| refactor | Code restructuring without changing behavior |
| docs | Documentation updates |
| build | Changes to the build system or dependencies |
| test | Adding or updating tests |
| release | Version releases |
Git log example
fix(TRPS-1987): reservations move upon hovering
feat(TRPS-3022): terminal capacity adjust graph
chore(TRPS-2944): migrate SCSS to use new module system
release: v1.17.2
Additional notes
Keep descriptions under 80 characters for readability.
Branch naming standards
Branch names should follow this format:
type/JIRA-ID-short-description
type aligns with commit types (feat, fix, chore, etc.).
JIRA-ID is the corresponding Jira ticket.
short-description is a brief, kebab-case description of the change.
Branch examples
feat/TRPS-3022-terminal-capacity-adjust-graph
fix/IARS-1070-accessns-request-reservation-date-issue
chore/TRPS-3025-timeline-code-improvement
Additional Notes
Use lowercase and hyphens (-) instead of spaces.
Avoid overly generic descriptions; be specific.
Keep branch names concise but informative.
Best practices
Rebase regularly: Keep your branch up to date by rebasing frequently, not just before merging.
Keep commits focused: Each commit should represent a single, logical change.
Write meaningful messages: Messages should clearly convey the purpose of the change.
Use feature branches: Avoid committing directly to main or develop.
Review before push: Run tests and linting checks locally before pushing.