Ever felt the frustration of inheriting a codebase with introduced code that no one actually understands why they were added? Well, I get it.
This is not a talk about atomic commits or how to be a git ninja. It’s a journey of understanding that we are not writing code for ourselves, and even if we’re, we are humans, we forget things.
Having good commit messages on a project can be a time machine, saving hours of head-scratching when deciphering historical changes. Also, it impacts the code review process and improves day-to-day collaboration.
Let’s explore the “how” we can leave some small tips for our future self or future developers that will touch our code and, most importantly, the “why” we should do it.
28. Culture
- Commit messages should answer:
- What was changed?
- What problem this commit solves?
- Why are we changing this piece of code?
- Complete the sentence “If applied, this
commit will …”
- Should be reviewed just as
another piece of code
45. Start Simple
- There's no strict definition of the ideal
commit message
- Indicate a logical change, a new feature,
fixing a specific bug
- If you can’t describe the change, split in
smaller ones