Improve your commits and Pull Request
Tags: git, beginners, productivity, conventionalcommits
Published: 2022-02-08 20:47:44

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!