5 ms·

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 yo

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.

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.