Skip to content

Instantly share code, notes, and snippets.

@joshbuchea
Last active July 2, 2025 11:54
Semantic Commit Messages

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:

@cfgnunes
Copy link

cfgnunes commented Apr 3, 2025

@nicholaswmin Great points!

I agree that simplicity is essential, and processes shouldn’t be added without a good reason. While Conventional Commits offers a broad set of keywords to provide flexibility, it's worth considering whether a smaller, more essential subset could cover most cases without unnecessary overhead.

That said, it's important to recognize that Semantic Commit, as it stands today, may not be useful for all types of projects. There’s no silver bullet in software engineering—it’s up to each team to evaluate what truly adds value to their workflow. Dismissing the project as "cargo cult programming" might be unfair; we risk misjudging its real purpose or, worse, falling into a Dunning-Kruger effect, where a lack of deeper understanding leads to oversimplified conclusions.

I believe discussions like these are valuable for refining tools, but at the same time, sometimes debates about tooling create more noise than the tools themselves—lots of talk, little action. Personally, I prefer to focus on building rather than overanalyzing.

Thanks for the exchange of ideas!

@nicholaswmin
Copy link

Ok to make this clear:

  • CC is good
  • The keywords must be drastically reduced

"Dismissing the project as cargo cult programming"

I'm not dismissing the project itself as cargo cult programming; that doesn't make sense.
I'm dismissing the overzealous adoption of unnecessary procecess/tools/conventions prematurely, for no concrete reason other than "I also do that"

@keithpjolley
Copy link

Curious what people do when more than one type of "thing" is done in a single commit. For instance, to polish up some python code before committing I ran RightTyper, Trunk format, and then added in some comments on the code.

"Learn to commit between each task" is good advice but sometimes that horse is already out of the barn.

@harizjet
Copy link

nice script @cfgnunes; but you can also use pre-commit hook to enforce it.

@major-phyo-san
Copy link

Hi friends, if I make some changes like bug fixes and feature addition and I have to update the dependency management code (eg, composer.json, package.json, pom.xml, build.gradle etc) to reflect my release version, what would be the commit message for it. For example, I have a PHP composer package that I develop and maintain. I add a bug fix and a feature. The previous version is "version": "0.0.8", and I need to update my package version to be "version": "0.0.9", what would be the commit message for that composer.json.

@qoomon
Copy link

qoomon commented May 19, 2025

In case you are looking for a more detailed git conventional cheatsheet feel free to have a look at https://gist.github.com/5dfcdf8eec66a051ecd85625518cfd13

@bgiddings
Copy link

I'm probably fighting a hopeless battle here, but I have to try. "Feature" should not be shortened to "feat".

"Feat" is already its own word, and it means "something that requires a lot of skill, strength, courage, etc. to achieve". Some features may be feats, but the vast majority of features are not feats.

@guneyozsan
Copy link

@major-phyo-san I used to use bump version and chore: bump version. But in our current project versioning is updated by CI using git tags so no more specific commits. In your specific example that would make 3 commits:

fix: nasty bug
feat: fancy button
chore: bump version

Side note per "Feat" vs "Feature, "Bug" is actually "a small insect" but anyway. Language is contextual, a collection of symbols interpreted within a context. If you leave the context out all words are useless junk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment