[AndrewHampton]

We've been following conventional commits for our front end code for the last year or so at my work. In other repositories, we've loosely followed the keep a change log conventions. I find conventional commits great when your repository will produce a package to be consumed by others. For example, conventional commits for our shared JS code helps us produce great change logs and helps us easily follow semver for the NPM packages our other applications use.

However, I don't find it that useful in the the final applications, even counter productive, since it typically will take up quite a bit of space in the commit title. Many of our front end devs completely ignore title length conventions now.

[jackcodes]

Why don’t they put the additional information in the body of the commit?

I see this in nearly every company I go to - everyone rushing to skip over adding anything useful to the permanent log by using git commit -m rather than a plain got commit.

[_asummers]

This is the place where (mentioned elsewhere in this thread) things like issue tracker links and other context can and _should_ go if you're using something like CC.

[AndrewHampton]

Oh, we do. We are generally pretty great at filling in good details in the body. I didn't mention that originally because I didn't think it was noteworthy.

The main problem is very commit titles that end up looking like:

  feat(SomeScope.OtherScope.Class): add support for abc and xyz option