The use of Git for us Devs is something essential, whether in personal projects, open source with many people or an entire community.
Given that, i...
For further actions, you may consider blocking this person and/or reporting abuse
You can also use gitmoji for this. So your refactor commit would be something like this:
git commit -m "♻️ changed markup"Downside is that you're searching for the right emoji most of the time...Sounds as useful as using ascii art for commit messages. But maybe, if you are fast with your emoji input, it could even be faster than typing a longer word... Or maybe a commit hook could sed "s/^refactor/♻️/" the message for you.
I’ve been thinking about a commit hook that would classify your commit message and then prepends the correct gitmoji. But haven’t found the time to learn about training a model as I’m new to it…
That's the main reason why i don't use emojis or talked about them here... But yeah, you can use them to make a commit look more aesthetic.
I strongly, as of a week or so ago when someone pointed it out to me, recommend not using
git commit -m. It encourages terse, pithy commit messages. In the week since I've banned myself from using it (via a shell function that yells at me when I try), and enforced use ofgit commit -vso I can see the diff in my editor when writing them, I think my commit messages have been greatly improved.or you could've just enabled -v by default.
git config --global commit.verbose trueThat won't prevent use of
git commit -mthough, it just turns on-vwhen you don't use-mto put your commit message on the command line.If you're going for clarity, "feat" should be "feature". The words do not mean the same thing.
Good point, but it's used as "feat" by the convention itself, it's on theirs docs... Check it out later.
Ah, sorry, I thought this was your invention. I will go and annoy them instead 😁
A very nice convention that I've been using this last year, it brings so much clarity and forces me to think about the meaning of what I'm committing.
However, I do not agree with the meaning of "refactor": I always
rebase -ithe code changes after a review. What do you think about it ?Essentially, Git "rebase" is deleting commits from one branch and adding them to another, we can say it's a destructive operation. Usually i prefer the "merge" since it's a non-destructive operation and the existing branches are not changed in any way.
As for the "refactor" the goal is to improve code readability and reduce it's complexities.
The use of them depends on the situation of course, but we shouldn't use only one type of operation.
refactor- A code change that neither fixes a bug nor adds a featureA lot of my commits lately are mostly refactor ;)
rebase -idoes not work on code level. If you rename things, split things, move things, change code flow without changing business logic - that refactor.This is what a new young team lead would come up as an idea or as "a new process to streamline xyz".
Unfortunately, no one will follow these conventions.
With scrum teams, no one really has the time. Instead I would focus on writing proper test cases with 100% functional code coverage.
Tests are surely a must have as well, but once you have the time to implement this commit convention, do it, this helps a lot the future devs that will look at the code.
You have all these information in the attached work item.
I fail to understand how this is useful at all.
Yeah it surely looks pretty but IMHO it doesn't add lot of values.
Someone else from the comments suggest to add emoji!!!. I mean seriously??!
Why waste time on things that doesn't matter or has no purpose.
I will be waiting for your future post on how effective this whole "pattern" is.
THANK YOU!
Despite having just over 3 years in the world of web development, every day I learn something new. It's fascinating! And I didn't know that there were really standards for how to write commits.
I had read some "recommendations", but after reading your post I did some more research, and the conventionalcommits.org site tries to establish a general standard.
Thank you for this information and for sharing it.
Big hugs and blessings from Venezuela.
Our whole team is commited to these conventions. We also built a tool which creates semantic versions/releases following a ruleset. Maybe you wanna contribute or give it a shot-> github.com/AOEpeople/semanticore
You should consider adding a reference to ticket number eventually if you work inside a team. Help a lot with code traceability.
I really wanna see this being used in our work as well, but I will try to use this first myself as I see some Vue.js and Nuxt Github repo's use this structure as well.
Good post 👍🏻
Thank you! I needed this
you can use commitizen
Thanks Chief. Really helped me here👌🏾
Great article! Thank you for sharing
idem than Hans i use gitmoji, and got poweful app on macX with raycast.com/ emoji.
Thanks for the article.
It's a great convention but in the end, it always ends up as a squash commit with "merge branch 555-my-branch into master"
I really like the style.
First example looked like my commits /s
Personally I prefer create a lot of commits with random name, and squashing all of them to a single, conversational commit after I have completed the task.
I use Conventional Commits on a daily basis. They also play nice with semantic release than will auto version (Semantic Versioning) and generate change logs based on conventional commits.
I do like this, and may have my Team do this as we have standardization around our branch names but not commits. Thanks for the brain food.
Nice Explanation, Thanks for sharing these valuable information.
thanks for information
We use commitlint.js.org/#/ to follow this pattern and it enforces it which is nice
hi there - many many thanks this is just mindblowing. Keep up the great work
Thank u for sharing
Helpful..
Really useful, thank you
Great article! I can't image using git without conventional commits in all of my projects!
Thanks alot for sharing it's so helpful and the explanation was so clear and easy to understand
Awesome, thanks! 😍