conventional-commits/conventionalcommits.org

I don't want to read

gswallow opened this issue · 11 comments

Create a chart rather than paragraphs of blah blah blah that I'm not going to read.

Tell me which words to use in my commit messages, without using too many words.

While the specification itself is reasonable in length, I do like infographics (everyone does — it only encourages adoption), and the types recommended by @commitlint/config-conventiona aren't included in the specification itself (which I think they should, despite being less important than fix and feat), and aren't even described at all (which I also endorse). Also, the specification itself should be more prominent on the website; it should precede the examples at the very least.

+1 for that priceless title

The spec could be left as-is, but I'm with @gswallow in wanting a chart, or at least something in tabular format. It could be in addition to, rather than a replacement for the spec.

I'm also a fan of infographics, although I'm trying to imagine what an infographic version of the spec would look like. A table is something I can paste locally (Markdown), even selectively. It could be a nice bit of copypasta to include in the hidden section of my/your repo's pull_request_template.md file.

The whole table is just:

word meaning
fix like SemVer's patch bump
feat like SemVer's minor bump
whatever you want have fun with it

Maybe also:

word meaning
fix! like SemVer's major bump (bugfix vibes)
feat! like SemVer's major bump (feature vibes)
whatever! like SemVer's major bump (fun vibes)

BREAKING CHANGE goes at the bottom.

Conventional Commits does not define any other words to use in our commits. It leaves the option to use other words so long as you stick to the format, and refers to one common convention as an example.

I was grumpy; I apologize for that.

I found a very helpful cheat sheet that I refer to:

https://cheatography.com/albelop/cheat-sheets/conventional-commits/

@gswallow great cheat sheet, thanks for sharing!

I would've gotten grumpy too. I think most of us come in thinking that "Conventional Commits" defines many commit types. If I was just trying to learn what those are so that I could get stuff done, I would've been equally frustrated.

I think adding a tiny chart to help digesting the spec would be helpful.
That's something we could add quite easily to the spec without any versioning changes.

Anyone in this issue wants to create a PR?

cc @bcoe

I think adding a tiny chart to help digesting the spec would be helpful.

@damianopetrungaro I agree, at work I try to distill conventional commits down to fundamentals when explaining it to people, i.e., most people only care about feat, fix, and occasionally breaking changes.

I'm an awful artist, do any contributors reading this thread have an idea for what a chart should look like?

@mentalisttraceur @gswallow @quadespresso if any of you know a designer (or you are good with it as well!), we're open to this idea.

Let me know!

Maybe we should try to implement a dynamically generated cheat sheet that get data based on the language and generates a pdf in a friendly printing format. I'm working on some sketches on figma...

This is from GPT. If it is accurate it might provide a base for work. (Can't comment as I just learned this project)

Type Description Example
feat A new feature feat: add user authentication
fix A bug fix fix: resolve issue with login timeout
docs Documentation only changes docs: update README with new instructions
style Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.) style: format code according to guidelines
refactor A code change that neither fixes a bug nor adds a feature refactor: simplify login function
perf A code change that improves performance perf: optimize image loading
test Adding missing tests or correcting existing tests test: add unit tests for login service
build Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) build: update dependency versions
ci Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) ci: add new CI pipeline for integration tests
chore Other changes that don't modify src or test files chore: update package.json scripts
revert Reverts a previous commit revert: undo changes in commit 1234abcd

This table covers the most commonly used types of conventional commit messages. Each type helps to categorize the nature of the commit, making it easier to understand the history and purpose of changes in a project.