Git is a very powerful tool installed on most of our machines. As developer, we use it every day.
But, unfortunately, at first glance, this tool is not very developer friendly. That’s why a lot of
people bypass the command line interface (CLI) with a graphical user interface (GUI).
It’s like using a framework without knowing the language itself. It can be OK at the beginning but,
sooner or later you, you will have problems.
Let’s take an example:
There’s might be nothing wrong for you with this log. Let me show you the issues I’ve found with this log:
- It’s hard to understand the Component’s history. We might repeat errors already fixed.
- There are unnecessary commits which pollute logs and make history hard to read. Also,
functionalities like
git blame
become irrelevant. - It seems that a feature was added by a few commits. Which commit should I include if I want to revert this operation?
4b99d9a
say something about a different component. Is it an unwanted change? Again, what if we need to revert?- …
I think we shouldn’t confound git commit
with ctrl
+ s
. A git log
should be like reading a
story. By reading the log, I should be able to understand in ~10s the whole file history.
What if we had something like this:
Way cleaner, isn’t it? That something called Conventional Commits.
Conventional commits
Conventional commits is a Git commit convention made by the Angular team. Basically, every pull request should end up with one commit and a standardized commit message.
The message should follow this regex:
Types of commit:
- feat: Add a new feature (equivalent to a
MINOR
in Semantic Versioning). - fix: Fix a bug (equivalent to a
PATCH
in Semantic Versioning). - docs: Documentation changes.
- style: Code style change (semicolon, indentation…).
- refactor: Refactor code without changing public API.
- perf: Update code performances.
- test: Add test to an existing feature.
- chore: Update something without impacting the user (ex: bump a dependency in
package.json
).
Project that uses this convention: Angular, Vue.js, Gatsby (almost), Lerna (almost), jest (almost).
Benefits
Project/code understandability
Commits are more descriptives and it’s easier to understand the project’s history. It became also
easier and to contribute.
For example, I never contributed to the Angular’s http package. But,
reading the repo’s git log helps
me to better understand this package’s history.
Usability
If you have one action per commit, it became easier to revert a change. Same if you have git
conflict…
Master your Git skills
Because not all Git-repository manager have a “squash and merge” option, you sometimes have to do
this operation by yourself. So, you will learn how to “squash” your commits, how to “fixup” a
commit, how to remove a specific commit… It’s always important to know what’s going on under the
hood!
See also
- conventionalcommits.org
- Vue.js commit convention
- github.com/conventional-changelog/conventional-changelog - A nice tool to generate changelog based on the git message.
- github.com/conventional-changelog/commitlint - A git commit linter. Use it with Husky.
About the author
Hey, I'm Maxence Poutord, a passionate software engineer. In my day-to-day job, I'm working as a senior front-end engineer at Orderfox. When I'm not working, you can find me travelling the world or cooking.
Follow @_maxpou