3 ms·

What's tremendously useful for us to have in the commit message, is the ticket ID the work is related to in our issue management system, to the point where it i

What's tremendously useful for us to have in the commit message, is the ticket ID the work is related to in our issue management system, to the point where it is practically mandatory. I see it as a matter of scoping communications. The issue management system includes a broader set of people than the git repo. You want the commit linked to the issue so that you can see the entire history behind the commit, including the business decisions, the designer making a call, the back and forth with QA etc. That can all be useful a year or two down the road if you want to understand why something was done a certain way. Now there is some info about the change that perhaps only the devs would ever care about, and probably that can sit in the commit messages. That sort of happens naturally but there's not really a lot of it for us. But that seems to me to be the relevant thing from an organizational perspective, no one writes commit messages except for devs, and almost nobody except the devs reads them.

Scubabear68 3y ago
This is what I came here to say. Assuming the team is working from JIRA or something, put the ticket number in the commit message. The ticket itself is where your “why” goes.
- jrs235 3y ago
  I wonder if Atlassian encourages and sells this as an ideal use case [for JIRA]. What a great way to make it really painful to leave their system if in order to make sense of your repo history you to need to maintain the references to their system. They are making your repo dependent on their ticket system...
- mook 3y ago
  It's really nice to have the actual reasoning in the commit history though. But maybe I was just scarred by the project that switched project management software like 5 times over its lifetime (but kept all of the commits) though.
  - aaronbrethorst 3y ago
    I’ve been through this in a job. The commit messages were borderline worthless, ostensibly the context was in a JIRA ticket that hadn’t existed in a decade, and I couldn’t figure out if a change was a mistake or something clever and poorly documented. It’s frustrating, a huge waste of time, and runs the risk of introducing subtle defects into the code today.
- davidjfelix 3y ago
  I can't stand the ticket number in the message. It's an immediate waste of 6-10 characters on meaningless metadata that GitHub can pull from the body and link for you. Further, the numbers are sequential, so frequently VERY similar, and highly prone to typos, which is harmful to anyone even minorly dyslexic.
  - Spivak 3y ago
    > that GitHub can pull from the body I think that breaks the thing that people want which is being able to `git commit -m "Fix #234353"` without a body at all.
    - davidjfelix 3y ago
      Use multiple messages. `git commit -m "Fix actual words that humans read" -m "Fixes: #234353"` You could probably script this based on branch if you're one of those people who names branches after ticket numbers. But my actual advice is that I think -m is a bad pattern that leads to bad commit messages, and omitting the message argument opens your EDITOR, and you should use that.

Scubabear68 3y ago

This is what I came here to say. Assuming the team is working from JIRA or something, put the ticket number in the commit message. The ticket itself is where your “why” goes.

jrs235 3y ago
I wonder if Atlassian encourages and sells this as an ideal use case [for JIRA]. What a great way to make it really painful to leave their system if in order to make sense of your repo history you to need to maintain the references to their system. They are making your repo dependent on their ticket system...
mook 3y ago
It's really nice to have the actual reasoning in the commit history though. But maybe I was just scarred by the project that switched project management software like 5 times over its lifetime (but kept all of the commits) though.
- aaronbrethorst 3y ago
  I’ve been through this in a job. The commit messages were borderline worthless, ostensibly the context was in a JIRA ticket that hadn’t existed in a decade, and I couldn’t figure out if a change was a mistake or something clever and poorly documented. It’s frustrating, a huge waste of time, and runs the risk of introducing subtle defects into the code today.
davidjfelix 3y ago
I can't stand the ticket number in the message. It's an immediate waste of 6-10 characters on meaningless metadata that GitHub can pull from the body and link for you. Further, the numbers are sequential, so frequently VERY similar, and highly prone to typos, which is harmful to anyone even minorly dyslexic.
- Spivak 3y ago
  > that GitHub can pull from the body I think that breaks the thing that people want which is being able to `git commit -m "Fix #234353"` without a body at all.
  - davidjfelix 3y ago
    Use multiple messages. `git commit -m "Fix actual words that humans read" -m "Fixes: #234353"` You could probably script this based on branch if you're one of those people who names branches after ticket numbers. But my actual advice is that I think -m is a bad pattern that leads to bad commit messages, and omitting the message argument opens your EDITOR, and you should use that.