All the companies try their best to make a unified way to work, from making the website more maintainable to making the response of the api faster.
This time I'm going to be focused on commits, and you are starting asking "Commits?" Yes! commits! :)
When you are doing your first steps with git you start typing whatever comes to your mind that reflects correctly what you did and if you think about it no one writes, in the same way, a commit.
Also, there are times that you need to deliver something really fast and you don't have time so you type in your commit something like these:
- lint fix
- test
- wip
- fix deploy
If for some reason the is a bug in the application and you need (for some reason) to read the history con the file or commits, you will see those types of commits. I saw worst comments than above, believe me
That's when conventional commits comes in the scene.
So...What are conventional commits?
Basically is a convention we use on top of a commit message, to make our codebase clearer with some easy steps of rules that we need to follow
What are the benefits?
- We could have a more clean codebase and readable
- Generate CHANGELOG automatically and sectioned
- Easy to inform to everyone (tech and no tech people)
- Trigger builds
- Contribute easily to everyone
- Know what's going on in the PR
Let me know how to write it!
Rules
The rules are really simple! :).
Need to specify the type of commit/pull request that you did.
The template will be the following one:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Let's break into parts.
type => Mandatory
This will tell the type of change you are applying to the codebase.
Possibilities:
- fix
- feat => feature/enhancement
- build
- ci
- chore
- docs
- refactor
- test
Example: fix: validate user email
scope => Optional
With the scope, we are specifying even more where was the change.
Example:
fix(api): validate user email
description => Mandatory
This will remain the same way that we are doing nowadays. Just commit with a message and be as specific as you can
body => Optional
If you need to clarify even more you could add a body
Example:
fix(api): validate user email
We need to add validation on the email so it can be created properly in our system.
footer(s) => Optional
You could use that for reference whatever you want. For example, in case of a rollback you could do like this.
Example:
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
Special Attention => Important!
sometimes we are adding some code that it could lead to breaking the application.
In those mark them in two ways.
- Adding in the type as BREAKING CHANGE
- Adding an exclamation mark !.
In my opinion, I prefer the exclamation mark.
Example
fix(api)!: validate user email
There are some tools to apply this without any mistakes? Sure! there you go.
Tools
For VSCode Lovers
https://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits
For Vim Lovers
https://carlosapgomes.me/post/bettercommitmsgs/
For WebStorm Lovers
https://plugins.jetbrains.com/plugin/13389-conventional-commit
For Pull Requests
https://github.com/zeke/semantic-pull-requests
With this, you and your team can have a unified way to have the commits, and also readable and understandable.
I hope you try the conventional commits. =)
If you need to read more about it
https://www.conventionalcommits.org/en/v1.0.0/
Please feel free to add your experience or thoughts about it.
See ya next time.
Ces!
Top comments (0)