Hacker News Reader

Comment by ttty | Hacker News Reader

You should always put the Jira/story id in the merge commit at least.

On GitHub you can also auto-close issues using certain keywords. I use "Fixes #123" for bug fixes and "Resolves #456" when completing features. The nice thing is that it will link to the issue in the GitHub commit history.

This seems to have become really pervasive the last few years, and I recognise it’s sometimes driven by regulatory/certification requirements. But in the absence of those, what does this gain you over putting a sentence or three of human-readable motivation into the commit message?

All the context from the issue that doesn't fit in a sentence or three?. Of course it depends, if the issue doesn't have context it's not important, but things like "who requested/reported this", "who was involved in decisions made", "what alternatives were considered and why where they rejected" might not necessarily fit in the commit message but exist in an issue.

If there's stuff that's valuable, I'd prefer to see it pasted into the commit message -- far less likely for links to get broken.

If it's long term valuable, i.e. "I considered obvious, attractive alternative algorithm X but it failed horribly because of Y", I'd prefer that to go in a comment in the code instead. Far more likely to still be noticed in three years time, after the code's been run through two different auto-formatters and otherwise mangled around.

So when you look at the Jira story you know where it is. When you deploy some code, how do you know what you actually deployed? You could look at the competed stories, but it's not that solid as checking merges with that story number

If you use Pivotal Tracker you can enable GitHub integration and either use the story id as the start of the branch name, eg, 12345-fix-foo, or reference it using [#12345] in the commit message to enable PT to add pushes and PRs to the story activity list.

unless your branch name matches the jira/story id

Put it in the commit message.

Especially for git, because old branches can be cleaned up/deleted which results in a loss of tracking.

So afterwards you look at the tree, find the matching merge commit containing the branch name and find the ticket that way?

Reply on news.ycombinator.com