|
3 | 3 |
|
4 | 4 | # English Version
|
5 | 5 |
|
6 |
| -WORK IN PROGRESS |
| 6 | +## Introduction |
| 7 | + |
| 8 | +Currently, in software development, even within the unique scope of a single language, a single implementation can be applied in many ways. When it comes to large-scale projects, there are always discrepancies in how each one tends to develop. From the most basic level, such as describing your work in your commit, to the most technical level, such as coding standards. |
| 9 | + |
| 10 | +From how you name a variable, to how you space a code block, or the methodology behind the order of imports used by a file, there is much that needs to be enforced rather than verbally reiterated. Tools like eslint, prettier can automatically check and format code and notify what is out of standard, as well as alert to bad code practices that often lie in details that go unnoticed in a review. Even when dealing with the most common tools in our field, it is possible to enforce a message pattern that greatly aids in the readability of our logs. |
| 11 | + |
| 12 | +Among these is a library called commitizen that can help enforce a conventional pattern for your project. |
| 13 | + |
| 14 | +## Commitizen Configuration |
| 15 | + |
| 16 | +Assuming we are dealing with a node project, we start by installing the commitizen global CLI, which provides a configuration wizard. |
| 17 | + |
| 18 | +```shell |
| 19 | +$ npm install commitizen -g |
| 20 | +``` |
| 21 | + |
| 22 | +With this, within our project, we can run the following command: |
| 23 | + |
| 24 | +```shell |
| 25 | +# npm |
| 26 | +commitizen init cz-conventional-changelog --save-dev --save-exact |
| 27 | + |
| 28 | +# yarn |
| 29 | +commitizen init cz-conventional-changelog --yarn --dev --exac |
| 30 | +``` |
| 31 | + |
| 32 | +Which will result in the following configuration within your package.json, which by default takes into account that you want to use the [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/) standard: |
| 33 | + |
| 34 | +```json |
| 35 | +"devDependencies": { |
| 36 | + "cz-conventional-changelog": "^3.3.0" |
| 37 | + }, |
| 38 | + "config": { |
| 39 | + "commitizen": { |
| 40 | + "path": "./node_modules/cz-conventional-changelog" |
| 41 | + } |
| 42 | + } |
| 43 | +``` |
| 44 | + |
| 45 | +With this, when running the command `git cz`, you will have access to the commitizen CLI, which will step-by-step guide you in defining a readable commit using the conventional-commit pattern: |
| 46 | + |
| 47 | + |
| 48 | + |
| 49 | +However, there is a problem here. |
| 50 | + |
| 51 | +When it comes to these types of automations, it is important to remember the intention of removing the manual user action dependency in general. While it is possible to remember to always run a `git cz` to always have access to the CLI, it would be much better to configure this CLI in a way that it accepts a `git commit` , seeing that this is a universal command and even used in conjunction with several flags that are not supported by `git cz`. Logically, the act of typing any of these commands is a manual process, one of them is so customary that it is basically an automatic process. |
| 52 | + |
| 53 | +To then configure this process automatically, we will use a library called husky. |
| 54 | + |
| 55 | +## Setting up a Hook to Catch Our Fish (considering that the fish is our commit and that our hook is not a real hook, but rather a symbol representing a point of capture and somehow it is possible to fish with just a hook.) |
| 56 | + |
| 57 | +The main objective of the husky library is to serve a variety of "hooks" throughout the execution of a commit where any action can be implemented. From linting files to our friend commitizen that we configured just before. |
| 58 | + |
| 59 | + |
| 60 | + |
| 61 | +For this, we will use the `prepare-commit-msg` hook, which runs just before the closing `commit-msg` hook. |
| 62 | + |
| 63 | +First, we install husky in the project as a devDependency (it will not in any way enter the compilation layer of an application, so there is no need for it to be a common dependency). |
| 64 | + |
| 65 | +```shell |
| 66 | +# npm |
| 67 | +npm install --save-dev husky |
| 68 | + |
| 69 | +# yarn |
| 70 | +yarn add --dev husky |
| 71 | +``` |
| 72 | + |
| 73 | +And right after the command `npx husky init`, which will create the .husky folder in our project, with a pre-configured example hook: |
| 74 | + |
| 75 | + |
| 76 | + |
| 77 | +Rename this hook to `prepare-commit-msg` and paste the following script into it: |
| 78 | + |
| 79 | +```shell |
| 80 | +#!/bin/sh |
| 81 | +. "$(dirname "$0")/_/husky.sh" |
| 82 | + |
| 83 | +if ! git rev-parse -q --no-revs --verify MERGE_HEAD # Ensure that GUI won't appear in case of merge commit |
| 84 | +then |
| 85 | + exec < /dev/tty && yarn cz --hook || true # Execute the cz command with the flag indicating execution within a hook |
| 86 | +fi |
| 87 | + |
| 88 | +exit 0 |
| 89 | +``` |
| 90 | + |
| 91 | +Now, when running `git commit`, the CLI will be automatically displayed: |
| 92 | + |
| 93 | + |
| 94 | + |
7 | 95 |
|
8 | 96 | # Portuguese Version
|
9 | 97 |
|
|
0 commit comments