5 ms·

I was taught by a previous manager always to follow: `add/update/remove/fix {feature/bug} by/with {reason} ({further explanation if required})` This also follo

by cwsx 6y ago

I was taught by a previous manager always to follow: `add/update/remove/fix {feature/bug} by/with {reason} ({further explanation if required})` This also follows what I've seen at a few companies since then. Would you say that's a general rule?

MaxBarraclough 6y ago
There's now an effort to (loosely) standardise this convention: https://www.conventionalcommits.org/en/v1.0.0/#summary https://www.conventionalcommits.org/en/v1.0.0/#summary
- jkaplowitz 6y ago
  Ah! That seems slightly different from the format the person you're replying to described, but I have seen this version in use at one job. There was only used by one person who gave no context on why he used that format, so it's probably no coincidence in such an example that to me the extra structure seemed to add only opacity and no real value. I can absolutely imagine that being different in a company that used this convention widely and built tooling around it. Doubly so when a lot of the staff is junior enough that it's helpful guidance for structuring thoughts around what the commit does.
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 ago
  I 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 ago
    Thanks 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.

by cwsx 6y ago

MaxBarraclough 6y ago

There's now an effort to (loosely) standardise this convention: https://www.conventionalcommits.org/en/v1.0.0/#summary https://www.conventionalcommits.org/en/v1.0.0/#summary

jkaplowitz 6y ago
Ah! That seems slightly different from the format the person you're replying to described, but I have seen this version in use at one job. There was only used by one person who gave no context on why he used that format, so it's probably no coincidence in such an example that to me the extra structure seemed to add only opacity and no real value. I can absolutely imagine that being different in a company that used this convention widely and built tooling around it. Doubly so when a lot of the staff is junior enough that it's helpful guidance for structuring thoughts around what the commit does.

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 ago
I 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 ago
  Thanks 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.