DEV Community

Cover image for Improve your commits and Pull Request
Cesar Muñoz
Cesar Muñoz

Posted on

Improve your commits and Pull Request

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
Enter fullscreen mode Exit fullscreen mode

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!
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)]
Enter fullscreen mode Exit fullscreen mode

Let's break into parts.

type => Mandatory
This will tell the type of change you are applying to the codebase.

- fix
- feat => feature/enhancement
- build
- ci
- chore
- docs
- refactor
- test

Enter fullscreen mode Exit fullscreen mode

Example: fix: validate user email

scope => Optional
With the scope, we are specifying even more where was the change.


fix(api): validate user email
Enter fullscreen mode Exit fullscreen mode

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


fix(api): validate user email
Enter fullscreen mode Exit fullscreen mode

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.


revert: let us never again speak of the noodle incident

Refs: 676104e, a215868

Enter fullscreen mode Exit fullscreen mode

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.

fix(api)!: validate user email
Enter fullscreen mode Exit fullscreen mode

There are some tools to apply this without any mistakes? Sure! there you go.


For VSCode Lovers

For Vim Lovers

For WebStorm Lovers

For 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

Please feel free to add your experience or thoughts about it.

See ya next time.

Top comments (0)