Commit Standards
Content
- One commit = one logical change
- Changes should be:
- Small
- Reviewable
- Understandable in isolation
- Avoid mixing:
- Refactors and features
- Formatting and logic changes
Rule of thumb
If a commit is hard to describe in one sentence, it is probably too large.
Message format
The commit message should be in the following format:
prefix: changes
more info
or additionally:
prefix(component): changes
more info
Prefixes
| prefix | meaning |
|---|---|
| feat | new feature (no refactors inside) |
| deps | dependency changes |
| tests | tests |
| docs | documentation |
| chore | indirect or maintenance changes |
| ci | CI/CD configuration |
| conf | configuration changes |
| fix | bug fix |
| fmt | formatting only (automated tools) |
| refactor | refactoring with minimal functional change |
| wip | work in progress (temporary commit which should not stay when a PR is open) |
Rules
Prefix
- Always lowercase
- Visual cue for quick scanning
- If you are modifying one component of the system, you can specify it by adding the component name into the brackets
Changes
- Start with a verb (
add,update,remove,fix) - use imperative mood - the commit message should complete the beginning of a sentence "This commit will ..."
More info (Optional)
- Separated by exactly one empty line
- Describes what changed, the developers thought process or any other context
- This should help mainly the reviewer to better understand the change in the given commit
- Refrain from using this place from storing the intent of the code - this should be either aparent from the code or placed in comments / documentation
Examples
fix: report correct mission status during landing
Detect the landing by checking the switch to landoff_tracker.
Add landing state to the mission_status enum.
feat: call rth when idle and low battery
tests(detector): add test for simple incoming image