[HN Gopher] Writing good commit messages
___________________________________________________________________
Writing good commit messages
Author : fanf2
Score : 16 points
Date : 2024-05-20 12:06 UTC (10 hours ago)
(HTM) web link (www.chiark.greenend.org.uk)
(TXT) w3m dump (www.chiark.greenend.org.uk)
| captainkrtek wrote:
| Good stuff here. I joined a team years ago that had a pretty
| solid and consistent practice of writing thorough commit
| messages, while still being somewhat concise. We made good use of
| the space to also include links to reference docs/tickets/etc.
| for follow up. This was incredibly useful in the long run when
| we'd be bisecting changes to identify a bad commit or just
| understanding the history of a small but important change (eg:
| why did we set this flag?). Its effectively free documentation
| space that costs nothing to add detail to.
| cynicalsecurity wrote:
| No one reads git history any way. Instead of writing commit
| messages, better write code.
| chatmasta wrote:
| If you write good commit messages, you'll read them when you
| come across them. Debugging a problematic commit is less
| painful when its commit message teleports you back in time to
| when it was written, and clearly expresses the intent of the
| change.
| louwhopley wrote:
| For solo-private projects, I constantly catch myself writing full
| commit messages even though I never read it again, and `git
| commit -m "."` would suffice.
| ElijahLynn wrote:
| The main thing I consider now is writing the commit message so
| that if I'm scanning it I'll know what I changed.
|
| I only use squash and merge now, no more reverting reverts, no
| more merge commits. So the PR or MR title is the commit message,
| which means writing good PR / MR titles.
___________________________________________________________________
(page generated 2024-05-20 23:02 UTC)