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

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.

I learned something useful today, thanks!

useful

very cool

Hi, if I add a new library like Bootstrap files to my project before creating the index.html, what tag should I use? I’ve been using 'chore' but it might be misleading. What do you think?

feat: Include Libraries?

But I'd also just include them in the same commit with
feat: Initial Commit