Recording change usefully.
WHAT A COMMIT SHOULD BE
One logical change.
WHY
So it can be understood, reviewed and reversed independently.
WHAT NOT TO COMBINE
A behaviour change and a formatting change Several unrelated fixes Work in progress that does not function
WHY NOT FORMATTING WITH BEHAVIOUR
The real change becomes invisible among hundreds of reformatted lines.
WHAT A MESSAGE SHOULD SAY
What changed, and why.
WHAT IT SHOULD NOT SAY
"Fixes" "Updates" "Changes"
WHY THE REASON MATTERS
The code shows what changed. Only the message can explain why.
WHAT TO REFERENCE
The issue or ticket, where one exists.
WHAT TO DO BEFORE COMMITTING
Review your own change.
WHAT THAT CATCHES
Debug output left in Commented-out experiments Accidental inclusions Secrets
WHAT TO COMMIT FREQUENTLY
Working states, so there is always somewhere to return to.
