|
|
|
|
|
|
by YorickPeterse
2206 days ago
|
|
|
Counter point: I have also worked for 10 years, and I keep running into people wishing developers spent more time writing better commit messages. I think what matters is the type of project. A lot of commercial software is all about moving fast and not caring too much about the past. In such a setup, writing good commit messages may be less useful or even seen as a waste. For software built to last however, I think good commit messages are invaluable. Issue trackers are replaced, documentation is rewritten or lost, comments are modified; but commit messages stay the way they are. This helps you get a better understanding of why decisions were made, something rarely documented properly. |
|
|
that's not at odds with what the GP posted.
I've worked in places where people spent a lot of time and effort 'improving' commit messages - reviews on those, rewriting, meetings, etc. after several months, the 'team' such as it was was writing 'better' messages per the few people who made the determination as to what 'better' was. they were the people who made it a focus and said this was necessary.
bug reports didn't go down. time to turn around functionality and fixes didn't go down. code review time didn't really go down. we didn't get more code coverage. code didn't execute faster. no one we delivered business value to was happier, or got more value. not in the immediate moment these changes took place, nor in the months that followed.