[HN Gopher] Using Git Commit Message Templates to Write Better C...
___________________________________________________________________
Using Git Commit Message Templates to Write Better Commit Messages
Author : ingve
Score : 53 points
Date : 2022-01-12 18:58 UTC (4 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| jasonpeacock wrote:
| This is a good idea, but in practice after a few commits you
| learn all the principles and don't need a wall of text in your
| commit template. Getting feedback in your PRs about your commit
| messages helps quickly reinforce learning these best practices.
| (you do review the commit message when doing PRs, right? ;)
|
| I'm a big fan of Conventional Commits[1], so my commit template
| reminds me of the types and provides an actual template to
| describe my change: <type>(optional scope):
| # type: build ci chore docs feat fix perf refactor revert style
| test Problem: Solution:
| Testing: Issue:
|
| Where Problem describes why this change is needed, Solution is
| what this change delivers, and Testing is how this change was
| validated. Issue is the JIRA/Github issue related to this change.
|
| EDIT: The Problem/Solution/Testing/Issue is not part of
| Conventional Commits, I added those to give structure to the
| body.
|
| [1] https://www.conventionalcommits.org/en/v1.0.0/
| JoelMcCracken wrote:
| I also like the problem/solution format, it gives a ton of
| context.
| wodenokoto wrote:
| I like it, but I feel like it is closer to a merge request
| message / merge / rebase commit message.
|
| Generally I think it is good form to break down your stories so
| they match the scope of a reasonable merge request and name the
| branch [issue-id]-human_readable_text
| jakeinspace wrote:
| Agreed. I can't imagine working on a feature branch and writing
| 50 of these for a moderately large change, just for those to be
| squashed. I mean, I can, but I don't think it's necessary.
| charcircuit wrote:
| It that case you can put in the detailed commit messages
| later. So when you are doing your squash you type in the
| detailed commit.
| mnahkies wrote:
| I wish that github would stick multiple commit messages into
| the default pr body - if I have a single commit it'll prefill
| the pr body from its message, but have a series of commits it
| won't. Should use the same rules as it's default squash message
| IMO
| TAKEMYMONEY wrote:
| A noble effort but in my experience these just get ignored. 90%
| of the PRs at my org have the empty, unfilled template text at
| the top of the description, a few line breaks, and then the
| _actual_ description underneath.
| jasonpeacock wrote:
| 1. Implement automation to flag and block/reject bad commit
| messages.
|
| 2. Educate and train ppl to include commit messages when they
| do code reviews
|
| or 3. give up and move on because your org doesn't care.
|
| Because this is a culture (not code) smell and changing culture
| is hard and needs support from the top.
| yakshaving_jgt wrote:
| That's unfortunate, and I think your experience reflects most
| places I've worked at too. It doesn't have to be that way
| though; technical leadership on a team can _choose_ to care
| about this kind of thing and coach their colleagues into caring
| more about writing communicative commit messages.
|
| To any technical leaders reading this comment, I encourage you
| to choose to care about this :)
|
| Here's the post I always share on this:
| https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...
| gaoshan wrote:
| We immediately kick them back if this is the case.
| Scea91 wrote:
| For me, commits are too low granularity. I usually give 1-2
| sentence summary.
|
| I put detailed descriptions (sometimes multi-page with graphs and
| tables) into pull-requests.
| woodruffw wrote:
| I had no idea `git` supported a template for commit messages.
| Very cool!
|
| It doesn't enforce Conventional Commits, but I use this[1] to
| lint my commits in conjunction with a Sublime Linter plugin[2].
|
| [1]: https://yossarian.net/snippets#git-lint-commit
|
| [2]: https://packagecontrol.io/packages/SublimeLinter-contrib-
| git...
| teeray wrote:
| My commit messages usually just try to answer the prompt "why
| does this commit exist?" That's because future me will be asking
| that when I open the commit after finding it in `git blame`.
| [deleted]
| thot_experiment wrote:
| my commit message template: "[profanity], wow this has been
| sitting for [number of months] with uncommitted changes that i
| don't remember the purpose of, committing so that if i break
| more stuff i have a point to roll back to"
| infogulch wrote:
| The prompt that I use in my head is finishing the sentence
| "Applying the diff in this commit will...". Examples:
| Change the submit button color to green Bump library
| XYZ to 1.2.3 Refactor and simplify the cart repository
| [deleted]
| splix wrote:
| I'm a big fan of problem/solution format.
|
| I.e. something like _"problem: suboptimal routing for upstreams
| in different datacenters; solution: additional role to separate
| primary and secondary upstreams"_.
|
| Also I consider commit message as a message to someone who would
| deal with that piece of code maybe years from now. And he would
| wonder why these lines even exist, and if he can replace them
| with some new logic.
| einpoklum wrote:
| My approach is to reserve the verbose discussion for the issue
| tracker and then keep the commit message short with "fixes #NNN:"
| and a short description of what's changed without motivation,
| design considerations etc.
___________________________________________________________________
(page generated 2022-01-12 23:00 UTC)