DEV Community

Discussion on: Write Git Commit Messages That Your Colleagues Will Love

Collapse
 
jmccabe profile image
John McCabe

Bit of a sudden ending to the story; I thought you might continue to talk about the (much neglected) body, and why you shouldn't accept the default message on merge commits when your source and destination branch have the same name (when there's a reasonable chance a rebase would be more appropriate).

Collapse
 
pictor13 profile image
Igor Pellegrini

I also was hoping in more juice about the body. It's a whole topic itself.
Commit titles are imho easy to write; and they don't really solve the "lack of context" problem. That's what commit body is for: the details that one will spend hours/days to guess/investigate by themselves.

Stuff like:

  • examples of a newly added command with description of options/parameters (as most of the times we don't add enough markdown documentation)
  • a reference to multiple tickets or, better, special keywords to interact with rather than just referring them (e.g. close a ticket with a commit). Or even references to multiple ticketing systems (I use Redmine for corporate collaboration and Gitlab issues more for self-management)
  • TODOs or missing features (as described above, an Issue Tracking System might not be available one day)
  • insights on what dirty detail of the code forced to perform the changes brought by the commit
  • if it makes sense to use Markdown or formatted code in the commit body (sometimes it does)
  • what kind of URLs or references makes sense to add

There are just some of the aspects that I find myself dealing with into commits' body.