"value":"\n <p>For some time, I've written commit messages following the Conventional Commits specification, where you start the subject with the type of commit - such as <code>feat<\/code>, <code>fix<\/code>, <code>chore<\/code>, <code>docs<\/code>, etc - and provide an optional scope before completing the subject line (the first line in the message).<\/p>\n\n<p>Then, it is encouraged to add a longer body to the message and provide any links and task IDs that the change relates to.<\/p>\n\n<p>Now I've been using it for a while, I'm deciding whether it adds value for me and whether it's worth me using it.<\/p>\n\n<p>I don't create automatic CHANGELOG files from the commit types.<\/p>\n\n<p>The scopes are usually arbitrary, it's unclear which scope (or scopes) should be added, or it repeats the module name I'm working on (which I could see from the Git diff).<\/p>\n\n<p>While I see value in writing descriptive commit messages, I'm unsure if I do to format the subject line in this way.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the thing<\/h2>\n\n<p>I like to use an iterative approach to my workflow. I like to try things and see if they work for me. If not, I can stop or continue iterating.<\/p>\n\n<p>If working with others, should you focus on writing commits that categorise commit messages within their subject or writing descriptive commit messages that capture why the change is needed?<\/p>\n\n<p>Which provides the most value when looking back at the Git log in the future?<\/p>\n\n ",
"format":"full_html",
"processed":"\n <p>For some time, I've written commit messages following the Conventional Commits specification, where you start the subject with the type of commit - such as <code>feat<\/code>, <code>fix<\/code>, <code>chore<\/code>, <code>docs<\/code>, etc - and provide an optional scope before completing the subject line (the first line in the message).<\/p>\n\n<p>Then, it is encouraged to add a longer body to the message and provide any links and task IDs that the change relates to.<\/p>\n\n<p>Now I've been using it for a while, I'm deciding whether it adds value for me and whether it's worth me using it.<\/p>\n\n<p>I don't create automatic CHANGELOG files from the commit types.<\/p>\n\n<p>The scopes are usually arbitrary, it's unclear which scope (or scopes) should be added, or it repeats the module name I'm working on (which I could see from the Git diff).<\/p>\n\n<p>While I see value in writing descriptive commit messages, I'm unsure if I do to format the subject line in this way.<\/p>\n\n<h2 id=\"here%27s-the-thing\">Here's the thing<\/h2>\n\n<p>I like to use an iterative approach to my workflow. I like to try things and see if they work for me. If not, I can stop or continue iterating.<\/p>\n\n<p>If working with others, should you focus on writing commits that categorise commit messages within their subject or writing descriptive commit messages that capture why the change is needed?<\/p>\n\n<p>Which provides the most value when looking back at the Git log in the future?<\/p>\n\n ",