2 ms·
Meh. This post is not harmful, but focuses on syntax and fails to insist on the most important thing: tell WHY you made the change; the what and how are already
by ronjouch 8y ago
Meh. This post is not harmful, but focuses on syntax and fails to insist on the most important thing: tell WHY you made the change; the what and how are already apparent in your code.
See Greg Ward at PyCon 2014: "Documenting history, or How to write great commit messages". His talk starts at 6:07. Direct link: https://www.youtube.com/watch?v=Jb6ij4eRu6c#t=367 https://www.youtube.com/watch?v=Jb6ij4eRu6c#t=367
- joe8756438 8y agoThis is exactly right. It's easy enough to see WHAT happened by looking at the code. Of course you can document the WHY in code also, but that usually ends up in a comment that gets out of date. Whether you're trying to figure out why the shit hit the fan or understanding a new codebase: commit messages that explain reasoning are gold.
- tobeportable 8y agoI still follow my past team definition of a good commit : the commit message should answer in it's first line why this commit was done. Overtime I realized that when I git blame I never care what a commit does because this is always obvious by reading the code of the commit. The reason why, however, is most of the time not obvious at all.