Skip to content

Latest commit

 

History

History
133 lines (95 loc) · 3.66 KB

File metadata and controls

133 lines (95 loc) · 3.66 KB

Commit rules

Writing a good commit is far from being an easy task. This little guide will help you to improve your commit messages by avoiding common pitfalls.

Rules

Those rules are more tips than anything else, feel free to adapt them to your needs or only pick some of them !


Commit length

A commit should not exceed 50 characters. Instead of writing a long commit message, consider improving its content below.

Instead of:

Update the config file because the last one was causing issues on Ubuntu 19.10 and contained the wrong IP for the test server

Consider doing:

Update config file

- Fix issues on Ubuntu 19.10
- Update server IP address

📑 Please note that since 50 is pretty short, and to avoid making the message harder to understand by burdening it, you generally should avoid adding a final dot to your commit.


Commit tenses

Your commit should be seen as a whole sentence, constructed as: If I apply this commit, it will (...)

By using this method, your history will be much more readable. That's also why you should avoid past tenses and prefer the present. (Try this method on the following examples !)

Instead of:

> Refactored the source code  <- If applied this commit will refactored the source code
> Translated homepage         <- If applied this commit will translated homepage
> Created MailService class   <- If applied this commit will created MailService class

Consider doing:

> Refactor the source code    <- If applied this commit will refactor the source code
> Add homepage translation    <- If applied this commit will add homepage translation
> Create MailService class    <- If applied this commit will create MailService class

Commit meaning

Don't forget that during your project, you will write plenty of commits and this will build your whole history. That's why, whenever you have to dig up some old feature push a month ago, it may be a living hell.

To avoid this, try to write meaningful and concise commit messages, even if this seems obvious on the spot.

Instead of:

> Fix bug
> Fix again
> Fix this time it will work
> anjfes,hlsef

Consider doing:

> Fix wrong parameter type in MailService call
> Fix missing argument in MailService method
> Fix incorrect exit condition in MailService method
> Fix missing exit condition in MailService method

Commit theme

This one is more like a personal tip. Reviewing tons of commits is not the most pleasant task. Even when using the tips written previously, having dozens of short lines of text is not a very inspiring thing.

To solve this, I suggest you to put a little tag in front of each commit message . My favorite way to use it is with emojis: it is pretty understandable by anyone and only use one character on the 50 recommended. Moreover, each team can build and use its own custom emoji list.

This is also a good way to go back to a specific moment (were you looking for documentation ? Bug fixing ? etc.)

If you want a ready-to-use list, I suggest you to check my emoji list which is limited to 10 emojis to avoid confusion among the team.

> Add .gitignore file
> Create empty solution
> Add main method
> Add unit tests for the main class
> Fix incorrect assertion

Consider doing:

> 🔧 Add .gitignore file
> 🌱 Create empty solution
> ✨ Add main method
> ✅ Add unit tests for the main class
> 🐛 Fix incorrect assertion