Semantic Commit Messages

semantic-commit-messages.md

Semantic Commit Messages

See how a minor change to your commit message style can make you a better programmer.

Format: <type>(<scope>): <subject>

<scope> is optional

Example

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

More Examples:

• feat: (new feature for the user, not a new feature for build script)
• fix: (bug fix for the user, not a fix to a build script)
• docs: (changes to the documentation)
• style: (formatting, missing semi colons, etc; no production code change)
• refactor: (refactoring production code, eg. renaming a variable)
• test: (adding missing tests, refactoring tests; no production code change)
• chore: (updating grunt tasks etc; no production code change)

References:

• https://www.conventionalcommits.org/
• https://seesparkbox.com/foundry/semantic_commit_messages
• http://karma-runner.github.io/1.0/dev/git-commit-msg.html

How to increase MAJOR change? Are there any flag like: git commit -m "major: breaking change"

How to increase MAJOR change? Are there any flag like: git commit -m "major: breaking change"

I've seen in some places the usage of an exclamation mark, e.g chore!: update minimum node version, to signify a breaking change.

How to increase MAJOR change? Are there any flag like: git commit -m "major: breaking change"

I've seen in some places the usage of an exclamation mark, e.g chore!: update minimum node version, to signify a breaking change.

Yes, ! indicates breaking changes. See: https://www.conventionalcommits.org/en/v1.0.0/#commit-message-with--to-draw-attention-to-breaking-change

To remove a commented code, which one should I use? Chore or Style? Or another?

To remove a commented code, which one should I use? Chore or Style? Or another?

I would use chore or refactor, i.e. chore: remove unnecessary comments or refactor: clean up code comments.

Perhaps a lint: would also be useful.
I am including a new ESLint rule to an old codebase.
For the moment, most changes will be about adding ignoring comments for errors which can not be fixed automatically.
But even for the ones that can be fixed automatically I think lint: is a nice prefix.

Perhaps a lint: would also be useful.
I am including a new ESLint rule to an old codebase.
For the moment, most changes will be about adding ignoring comments for errors which can not be fixed automatically.
But even for the ones that can be fixed automatically I think lint: is a nice prefix.

Use chore: since your changes won‘t affect the build.

@phcoliveira The idea of semantic commit messages is that you don't have many options, hence you can pick it properly without much complexity.

@JoaoGH @uncenter chore should be the right one when removing comments. refactor only when you change symbol names, style only when reformatting (removing comments is not part of reformatting).

What would you use for removing an old / deprecated code ?

@oscarwiding I would personally go for chore (or chore! if it was public API), but only if the new implementation was committed separately. If your commit removes old code and adds new code, it's rather feat or fix (depending what the new code does in relation to the old) or in rare cases refactor (when only deprecating old symbol names and introducing new ones).

I'm looking for feedback by others though, but that's how I would approach the situation.

那你子涵吗名字步步惊心不

Which type can I use to commit a dependency update? I see the build(deps): type often, is it correct?

I use chore: bump deps even though that's probably wrong. build: bump deps makes sense, I'm not sure if the scope of deps that you have in the example build(deps): works though...

If I install tailwindcss and setup the main.css file, then what type should I use? chore(package)?

@mrkhairullah What kind of repository is this? Is it a web application? A documentation site? A monorepo? You need context. It might be refactor(docs): switch to tailwindcss (a repo with a docs/ folder), feat: use tailwindcss (a repo that is just for a website), etc.

@mrkhairullah If you are importing tailwindcss inside main.css for the first time and your application is using this css file, this will most likely impact your app, so I’d go with feat since it is not a fix and I would expect a new version tag for this.

@mrkhairullah What kind of repository is this? Is it a web application? A documentation site? A monorepo? You need context. It might be refactor(docs): switch to tailwindcss (a repo with a docs/ folder), feat: use tailwindcss (a repo that is just for a website), etc.

@uncenter yep web app for personal web use react and vite. When adding tailwind in package.json is a chore? and when adding main.css to commit in git use refactor or feat?

@mrkhairullah If you are importing tailwindcss inside main.css for the first time and your application is using this css file, this will most likely impact your app, so I’d go with feat since it is not a fix and I would expect a new version tag for this.

okey thanks @marijoo

Somthing i use when i do CI is

CI: Add eslint10

useful sir

Really useful.
Thanks

How about change the configuration?

How about change the configuration?

chore prolly

changing project structure, for example creating new src directory, and probably moving some filed into it, is in which type? docs, refactor, chore?

changing project structure, for example creating new src directory, and probably moving some filed into it, is in which type? docs, refactor, chore?

I'd go with refactor.

changing project structure, for example creating new src directory, and probably moving some filed into it, is in which type? docs, refactor, chore?

I'd go with refactor.

Depends. If it‘s a package and the changed project structure eventually impacts users, it could also be a breaking change which should be reflected in a version.

changing project structure, for example creating new src directory, and probably moving some filed into it, is in which type? docs, refactor, chore?

I'd go with refactor.

Depends. If it‘s a package and the changed project structure eventually impacts users, it could also be a breaking change which should be reflected in a version.

No visible change for users is made

Thanks!

What'd you suggest to use if I remove a feature?
If it caused bugs, it would be bugfix I guess. But what if it was just unnecessary?

What'd you suggest to use if I remove a feature? If it caused bugs, it would be bugfix I guess. But what if it was just unnecessary?

bugfix isn't a conventional commit type, it would be fix. That also could be considered something breaking, so you can use an exclamation mark to mark it as such: fix!: xyz and remove abc feature.