|
> Commit messages are the narrative of your project's history. They help others (and your future self) understand why changes were made, making collaboration smoother and debugging less of a nightmare. Yes. And yet: > - Keep each point brief and focused. > - Use bullets (-) and avoid lengthy explanations. No, they lost me there. You often can’t tell the necessary narrative in a single sentence, and you frequently can’t explain why changes were made briefly, and I strongly refute that “avoiding lengthy explanations” should be a goal in commit messages. I exceed ten lines very frequently, and when working professionally I’ve tended to exceed fifty lines at least twice a year. Coworkers have commented favourably on my commit messages, as unusually useful, and some have even lengthened theirs more often after experiencing them. I don’t know what my record is, but it was more than 300, though that was as part of a long-lived refactoring branch that I was needing to rebase every week or two for six months as I continued working on it, migrating from an in-house concatenation-and-#ifdef module builder to ECMAScript Modules, and I was maintaining the dozens of commits meticulously, some regenerated automatically and some requiring manual effort, and so I was detailing the semantics of the changes across a large number of files, so it might not count quite so much. But I’ve done over a hundred a few times for other reasons. Keep your mind open, and look at the longest commit messages in popular repositories, and you’ll find there’s a lot of scope for very long commit messages. —⁂— I loathe Conventional Commits. It saps the art out of the commit message, the tags are frequently badly applicable, the benefits are negligible to negative (changelogs shouldn’t be generated from commit logs—they should be their own thing), and they’re simply ugly. |