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.
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.
Something useful to add to your available type is chore. Such as deleting or renaming a file. Or changing a config like .gitignore which relates more to the repo itself than your application's build flow.
I started using build for only build-related configs - like a package.json or lint config file.
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.
Thanks! I've edited to include info on configuring the comment character. From git's documentation, both the # and ; characters are valid by default, but in case anyone wants theirs to be "🤫" or something, there is info on how to set it now!
This is great 😎. I was thinking if i was able to do such a think. It is very useful for dev teams working with git - issues - branches.
Thanks for sharing Timothy.
Frontend developer by day, iOS developer by night. Currently working on learning iOS development and my own blog, Mike Decodes, where I'm decoding the tech industry. Come hang out with me on Twitter!
Thanks for letting me know about this. I use git here and there and like the feature of template.
git config --global core.editor=nvim +14 -c 'startinsert' didn't work for me
I use arch, not sure if that's the reason, but for anyone having trouble with this.
My fix
git config --global core.editor 'vim +14 +startinsert'
cheers
Thanks for pointing this out, @haxnet . I've edited the article to include Neovim and Vim configurations, with links to more info!
Conventional Commits node package also does this for you but gives you a nice interactive cli asking you to choose / enter descriptions etc.
Thanks for this! It seems really slick. For anyone else interested, the project is called commitlint.
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!
That linked page looks good.
That's a lot of dotfiles. Here are just a few of mine github.com/MichaelCurrin/dotfiles
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.
Something useful to add to your available type is
chore. Such as deleting or renaming a file. Or changing a config like.gitignorewhich relates more to the repo itself than your application's build flow.I started using
buildfor only build-related configs - like apackage.jsonor lint config file.I actually had already been using
chore, but forgot to add it here! The article's been updated to include it. Thanks for mentioning it!You're welcome.
I'd appreciate if you have a look at my extension which doesn't let you choose a semantic message, it writes one for you.
github.com/MichaelCurrin/auto-comm...
There is also a nice vscode extension for conventional commits
Thanks, really useful.
You may want to add that the comment character is configurable. In my case is ; so I modified the template accordingly.
Thanks! I've edited to include info on configuring the comment character. From git's documentation, both the
#and;characters are valid by default, but in case anyone wants theirs to be "🤫" or something, there is info on how to set it now!Nice, thanks for sharing!
Just a minor typo: the git-config to set line 14 on vim should say
core.editorinstead ofcore-editor.Thanks for catching that! It’s been edited and updated. Cheers!
Thank you for sharing
Someone else may have pointed out already, but the "feat" and "fix" SemVer description is swapped.
featshould be SemVer MINORfixshould be SemVer PATCHThis is great 😎. I was thinking if i was able to do such a think. It is very useful for dev teams working with git - issues - branches.
Thanks for sharing Timothy.
I like the idea of creating a commit message template :). Might end up proposing this to the teams at my company!