[epage]

At $DAYJOB, we organically switched from not having any formal style to having an internal formal style. People seemed to want the benefits of tooling integration and clearer communication.

Right now, we are switching SCM's and are looking at adopting Conventional to replace our internal style. I've already started using Conventional and have really appreciated it. It makes it fast and succinct (remember, line length "requirements" in git) to get the information you need even in one-line logs. Also, it makes CHANGELOG maintenance easier, whether using an automated tool or doing it by-hand.

Not happy with the other ones, I've created my own commit style validation tool, committed [0] and have deployed it on my open source projects. Like code style enforcement in CI, I like delegating this to a tool since it makes the requirement very clear for contributors.

The one thing I'm disappointed with with Conventional is that they did not follow git conventions for multi-line trailers.

[0] https://github.com/crate-ci/committed

[mgoblu3]

Similar experience here. On really big teams sure, you can bike shed the format a ton, but they’re all relatively close enough but CC has some good tooling so we just ran with it. Results have been fine, didn’t waste a bunch of time debating it.

Haven’t figured out a good way to integrate co-authors easily with it though.

[epage]

Wouldn't Co-Authors just be a footer/trailer?