Git Commit Patterns
Tags: git, beginners, tutorial, productivity
Published: 2023-01-27 03:00:00

The use of Git for us Devs is something essential, whether in personal projects, open source with many people or an entire community.
Given that, it's important that we use **git commit** properly. Having a coherent and standardized language helps everyone involved in the project to understand the changes that have occurred.

![Bad Commit Timeline](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7r0qv3vii7v7yjxyxef2.png)

In the image above, we see how harmful a poorly commented commit can be, since we fail to understand the nature of the change that occurred and the context of it. In the long run, the effect is even more damaging, as the maintainability of the software suffers due to inconsistencies in the scope of these changes, and how they have affected the project in the past.

With that in mind, let's talk a little about **Conventional Commits Pattern**.

---

###What Is It?

[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) is a simple convention for commit messages, which follows a set of rules and helps projects to have an explicit and well-structured commit history.

---

###How To Use It?

The rules are very simple, as shown below we have a _type_ of commit, the context _(scope)_ of commit and the message _(subject)_ of commit.

```
!type(?scope): !subject
<?body>
<?footer>
```

Thus, `!` indicates the mandatory attributes and `?` indicates optional attributes.

---

###Subject: Imperative instead of past tense

In this way we are telling our team what the commit will do if applied.

> _“If applied, this commit will <message>”_

**“If applied, this commit will change the markup”**, which makes a lot more sense than: _“If applied, this commit will changed the markup”_

![Commit Subject use](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mfm2chjhctjdspyfl4t8.jpg)

---

###Type: What are the types of commits

The type is responsible for telling us what change or iteration is being made, from the convention rules, we have the following types:

- `test`: indicates any type of creation or alteration of test codes.
**Example**: Creation of unit tests.

- `feat`: indicates the development of a new feature for the project.
**Example**: Adding a service, functionality, endpoint, etc.

- `refactor`: used when there is a code refactoring that does not have any impact on the system logic/rules.
**Example**: Code changes after a code review

- `style`: used when there are code formatting and style changes that do not change the system in any way.
**Example**: Change the style-guide, change the lint convention, fix indentations, remove white spaces, remove comments, etc…

- `fix`: used when correcting errors that are generating bugs in the system.
**Example**: Apply a handling for a function that is not behaving as expected and returning an error.

- `chore`: indicates changes to the project that do not affect the system or test files. These are developmental changes.
**Example**: Change rules for *eslint*, add *prettier*, add more file extensions to *.gitignore*

- `docs`: used when there are changes in the project documentation.
**Example**: add information in the API documentation, change the README, etc.

- `build`: used to indicate changes that affect the project build process or external dependencies.
**Example**: Gulp, add/remove *npm* dependencies, etc…

- `perf`: indicates a change that improved system performance.
**Example**: change ForEach to While, etc…

- `ci`: used for changes in CI configuration files.
**Example**: *Circle*, *Travis*, *BrowserStack*, etc…

- `revert`: indicates the reversal of a previous commit.

![Commit Types use](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eu75nl5bcy3l4em3s87m.jpg)

_Note:_

- Only one *type* per commit;

- The *type* is **mandatory**;

- If you don’t know which *type* to use, it is probably a big change and it is possible to split this *commit* into two or more commits;

- The difference between `build` and `chore` can be quite subtle and can lead to confusion, so we must be aware of the correct *type*. In the case of Node.js, for example, we can think that when there is an addition/change to a certain development dependency present in `devDependencies`, we use `chore`. For changes/additions of common dependencies to the project, and that have a direct and real impact on the system, we use `build`.

---

###Scope: contextualizing the commit

At this point — and following past conventions — we managed to understand the type of change that was made in the commit _(commit type)_ and clearly understand what the commit will bring if applied _(commit subject)_.

Even though the scope is **not mandatory**, it can be used to contextualize the commit and bring less responsibility to the subject, making it as brief and concise as possible. **Remembering that the _scope_ must be inserted in the commit between parentheses**.

![Commit Scope use](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mfiv8rrjrf40zsupe1w6.jpg)

_Note:_ Scopes must be separated with `/`

---

###Conclusion

I wrote this article in order to record one of my learnings _(they were just some notes in the notion app)_, but I hope it can help other devs out there.