If you don't know about conventional commits, I would ask you to check them out here, but the gist of it is that, it is a standard way to structure your commit messages such that they are easier to understand at a glance. For instance, say you removed some logs that you had lying around in your code base, instead of writing a commit saying
minor changes
I normally write
chore(NameOfBranch): code cleanup, removing logs
This makes it easier for the person reviewing the code to know that I was not implementing a feature, I was just removing the logs.
Similarly for a new feature you could have a commit message that says
feat(NameOfBranch): <an explanationon your feature>
I find that this is more legible to track the progress of my work.
But why do I love conventional commits? Well its simple really, it makes me think just a bit harder about what I have done. It's a good mental check for me before I push my changes and open a PR. And I find that that pause to think moment really keeps me going.
Top comments (6)
As for curiosity, in big projects with others, do you try to raise it to make it a convention so all the team use that kind of commits?
I think they are a good idea and I also find commits as a way of mental check
I always try to make the team adopt conventional commits. But that's a bigger task than you'd expect.
Early in my version control days I didn't understand the advice to make good commit messages. I just thought you would try to summarize the changes happening. It became a pain because, you know I improved things (organize, add features, indent).
Git's history rewrite got so much flack, HG was better, you need a friendly ID. Nope, commit structure is valuable, it is the one human thing we have left in this world.
It really helps. Getting the whole team to adopt takes time. People are comfortable with their ways but I find that as a junior developer it is in my best interest to try and help them adopt it.
It allows me to work on multiple things at a time and even come back to things months later.