3 ms·
I've never seen that anywhere I've worked, though it's a readable enough format that it wouldn't bother me if someone decided to adopt it for a good reason like
by jkaplowitz 6y ago
I've never seen that anywhere I've worked, though it's a readable enough format that it wouldn't bother me if someone decided to adopt it for a good reason like compatibility with parsing by dev workflow dashboards or other automatic tooling.
Though, I'm not sure it's a helpful restriction for commits that clarify, refactor, or clean up code. One can certainly reference an issue tracker number as the {feature/bug} element that gives the necessary context, but the strictness spreads the information around more widely than is natural.
If someone was adopting that convention as a workaround for helping team members learn how to communicate, they're probably going to find that it's a very incomplete workaround.
- cwsx 6y agoI should note this is normally done on a feature branch (with the ticket number attached). i.e. feature/{ticket-#}-{ticket-title} When merging you can pretty easily see what ticket each commit was for. Seems superfluous to put the same information in every commit messages.
- jkaplowitz 6y agoThanks for the clarity. Yeah, I agree it would be unhelpfully repetitive if every commit in a given feature branch merge has nearly basically the same title. That's not best practice anywhere I've worked. By contrast, referencing the ticket number (but not necessarily ticket title) is common practice in the PR message, and seems much more helpful.