Several companies I’ve worked at wanted us to prefix our commits with the Jira ticket number e.g MIN-1533. So you can look through the commit history and see right away which ticket the person was working on.
This works excellently up until the point where it generates links or comments on the ticket itself. I've stopped using ticket IDs in commit messages because of that spam, and I rely on GitLab to reference the merge request (which does have the ticket ID) now.
On a different occasion, I found that ticket IDs do, in fact, expire when the ticketing system changes, so it becomes useless information then, too.
Overall, I've stopped caring about commit messages. I care about the context of the changes (especially on bisect or blame), but the message? Screw that. Give me well-contained commits. Rebase your branches before your Merge/Pull Request, sort them into commits that make sense from their contents, and give it a reasonable message that reflects what the commit was kinda-sorta supposed to do. Beyond that, don't waste time on commit messages.
For us, it was a switch from Bugzilla to Jira, and then from one Jira project to four. Effectively, six years worth og tickets gone. And at the time, a lot of developers did not care for making their commits self-explanatory, so we had one giant 100k line commit, and dozens of useless oneliners, all with messages that referenced one non-existent ticket. That was hell. So I've stopped caring about messages - and begun caring greatly about tooling associating those commits with the merge, and commits containing relevant information to relate the changes to the business requirement.
You can comment/transition/log jira tasks with commits without even opening jira. For example: git commit -m "JIRATICKET12 #time 1w #resolve #comment Jira comment"
Several companies I’ve worked at wanted us to prefix our commits with the Jira ticket number e.g MIN-1533. So you can look through the commit history and see right away which ticket the person was working on.
That makes a lot of sense for companies, thanks for that.
I put them at the end of the headline. What is neet is that Bitbucket transforms them to direct link to the corresponding Jira tickets .
This works excellently up until the point where it generates links or comments on the ticket itself. I've stopped using ticket IDs in commit messages because of that spam, and I rely on GitLab to reference the merge request (which does have the ticket ID) now.
On a different occasion, I found that ticket IDs do, in fact, expire when the ticketing system changes, so it becomes useless information then, too.
Overall, I've stopped caring about commit messages. I care about the context of the changes (especially on bisect or blame), but the message? Screw that. Give me well-contained commits. Rebase your branches before your Merge/Pull Request, sort them into commits that make sense from their contents, and give it a reasonable message that reflects what the commit was kinda-sorta supposed to do. Beyond that, don't waste time on commit messages.
I was gonna mention the ticketing system changing. Happend to me in the past we moved to a different Jira board so a lot of links did now work anymore
For us, it was a switch from Bugzilla to Jira, and then from one Jira project to four. Effectively, six years worth og tickets gone. And at the time, a lot of developers did not care for making their commits self-explanatory, so we had one giant 100k line commit, and dozens of useless oneliners, all with messages that referenced one non-existent ticket. That was hell. So I've stopped caring about messages - and begun caring greatly about tooling associating those commits with the merge, and commits containing relevant information to relate the changes to the business requirement.
You can comment/transition/log jira tasks with commits without even opening jira. For example: git commit -m "JIRATICKET12 #time 1w #resolve #comment Jira comment"
support.atlassian.com/bitbucket-cl...