I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
Can I suggest updating your example to match the style that is actually recommended on Conventional Commits site which you linked to.
-(docs): Update README with contributing instructions
+docs: Update README with contributing instructions
Remove the brackets. Brackets are for scope.
Based on the link, if you were working on adding a language to the docs, you could add scope.
docs(lang): Add Polish section
I think the scope is also useful for module. For example if you have foo and bar in src directory, you would do feat(foo) to show the commits are scoped to the foo module.
The scope can be whatever you want but the advice is your team needs to agree on it and stick to it.
Thanks for mentioning this. When I originally started using the convention, I didn't use the scope/module designator, since for many smaller projects it can be overkill. I just kept the parentheses around the type for aesthetics, but I see how that could be confusing for someone adopting the conventional method (and/or make the template incompatible with other conventional commit tools). I've updated the article to include these changes, and also added more info on structuring a commit message in my git configuration.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
Can I suggest updating your example to match the style that is actually recommended on Conventional Commits site which you linked to.
Remove the brackets. Brackets are for scope.
Based on the link, if you were working on adding a language to the docs, you could add scope.
I think the scope is also useful for module. For example if you have
fooandbarinsrcdirectory, you would dofeat(foo)to show the commits are scoped to thefoomodule.The scope can be whatever you want but the advice is your team needs to agree on it and stick to it.
Thanks for mentioning this. When I originally started using the convention, I didn't use the scope/module designator, since for many smaller projects it can be overkill. I just kept the parentheses around the type for aesthetics, but I see how that could be confusing for someone adopting the conventional method (and/or make the template incompatible with other conventional commit tools). I've updated the article to include these changes, and also added more info on structuring a commit message in my git configuration.
Cheers!
Happy to help :)
Also you could turn your help message into a shell alias or a bookmarked page / gist so you can read it anytime without committing.
That linked page looks good.
That's a lot of dotfiles. Here are just a few of mine github.com/MichaelCurrin/dotfiles