Hacker News Reader

Comment by nicbou | Hacker News Reader

Same. I'll also add that this company's policy of prefixing commit messages with ticket IDs was a godsend. I could trace confusing business logic to a meeting and specific people. It made a big refactor possible. Not easier, possible.

Even as a solo worker, descriptive and atomic commits are valuable. They make merging or reverting changes a lot easier.

View on HN

Ticket IDs on commits, so useful.

Just the other day I wanted to find an old ticket which I couldn’t find via search. But I knew what changed in the code so I went to pull up the commit and… no ticket ID. And git does not provide any way to see which branch a commit was originally made to (our branches all have ticket ids in them).

I finally found it by searching PRs but it was painful.

My IDE leaves my previous commit message in the box which is awesome for me. Once I’ve committed once I just have to delete everything after the ticket ID and add my new commit message.

Ticket IDs are useful and low effort, especially if the previous developer entirely failed to document business logic in tests.

However, those hyper-detailed commit messages that some people seem to like? High cost, very low payback. Better to put all that effort into other docs instead.

I don't mind ticket IDs, but "Fixes #125" is not a very helpful message. Now I need to cross-reference an issue tracker just to understand what changed. I've been at places that required the ticket title be posted as well and that worked well. Humans could quickly see what changed and tooling could get triggered.

> However, those hyper-detailed commit messages that some people seem to like? High cost, very low payback. Better to put all that effort into other docs instead.

I guess I'm one of those people? I don't think the cost is very high. It's certainly no higher than putting them into another document. I don't get the emphasis on "very low payback" though. I've had to dig into projects where those detailed comments saved me weeks of effort. I love reading the rationale and any associated pitfalls with a nice code diff contextualizing the whole thing. And it's right there, easily accessible in my SCM log, where it integrates with the CLI and IDE. No 404s or issues because the startup that created the project died or was sold and the domain is no longer in use.

I thought it was an absolute standard to put the ticket number in the commit. Are there projects which don’t use it? How does Jira find the commits associated to the issue?

I do it even on small personal projects, as soon as it’s evident it will go to production, I set up an issue tracker and commit messages. As common as setting the linter files in TS by default, even when just drafting a POC.

I only saw it in one team, and implemented it with every other team after that.

We have ticket IDs in the branch names. Also a nice Jira <-> GitLab integration. When branch is merged the ticket status is updated.

We also name all branches after our Jira tickets, and our merge commit into the main branch is always: `TICKET-XXX - TICKET SUMMARY`. When we close the ticket in Jira, we also link back to the merge commit.

The Merge commit also updates the ChangeLog with the `TICKET-XXX - TICKET SUMMARY`.

That makes it really easy to trace things, as you can:

  - Look at the ChangeLog
  - Do a `git log --first-parent`
  - Look at a Jira Ticket and jump straight to the merge commit

We also have policies in that every commit to master must be a merge commit and associated with a Jira Ticket. Also, each branch is tied to one and only one Jira Ticket.

Reply on news.ycombinator.com