
I came across pre-commit hooks a while ago and I was amazed by how easy it is to use and how much it can improve your git workflow. I got to see how useful it can be especially when working on large project or when lots of developers are working on a repository.

The good thing about pre-commit, is that it’s quite straightforward to setup. To showcase how easy it is, I’ll use mypy as an example, as this is a real pre-commit hook I had to setup on one of our repositories.

Just a refresher - mypy is a static type checker for Python. It is used to find bugs mostly related to types in your code without actually running it. For more information about mypy you can checkout my previous blog post about it - [mypy](/blogs/mypy-integration)

To set up a pre-commit hook that will run mypy before allowing a commit, you can use the pre-commit library, which is a tool (or a framework actually) for managing and maintaining multi-language pre-commit hooks. Of course, you can use it for every check you like such as linting, testing, etc.

Here are the steps to set it up:

1. Install the pre-commit framework. If you haven't already installed it, you can do so with pip/poetry:

```bash
pip install pre-commit # pip
```

```bash
poetry add pre-commit@latest --group dev # poetry
```

2. Create a `.pre-commit-config.yaml` file. This file is used to configure what actions pre-commit will take. The .pre-commit-config.yaml file is typically placed at the root of your repository as pre-commit tool will look for this file in the root directory by default when it runs.

Here's an example of what it might look like for running mypy:

```yaml
repos:
  - repo: https://github.com/pre-commit/mirrors-mypy
    rev: v1.4.1
    hooks:
      - id: mypy
        args: ['--config', 'mypy.ini']
        files: ^src/
```

This configuration tells pre-commit to use the mypy pre-commit hook from the mirrors-mypy repository.
The rev field should be set to the version of mypy you want to use, while the args are the CLI arguments you want to it to run with, in the case as exampled above, i’m just passing mypy’s config file that already includes all the desired flags.

3. Install the git hook scripts. You only need to do this once after cloning the repository.
   You can do this by running the following command in your git repository:

```bash
pre-commit install
```

This will install a pre-commit script in your `.git/hooks/` directory that will automatically run your configured hooks when you run git commit.

4. Test the pre-commit hook. You can test the hook by trying to make a commit. If mypy finds any type errors, the commit will be blocked.

Couple of additional notes:

- Keep in mind, by default, pre-commit runs only on files that are staged for commit, but you can configure it to run on all the project’s file if you’d like just by telling it to check all .py files for example.

- Once someone clones the repository, in order to contribute, running the install command of pre-commit is a must. I'm aware there are some methods available to do this automatically, but i haven't seen one that I like.

- Uploading the `.git/hooks` directory into github is not recommended of course.

- If you wish to place your .pre-commit-config.yaml file elsewhere which is not the root directory, such as in a .github/pre-commit/ directory, you can do so by specifying the `PRE_COMMIT_CONFIG_FILE` environment variable to point to its location.
  For instance, if your .pre-commit-config.yaml is in .github/pre-commit/, you can set PRE_COMMIT_CONFIG_FILE as follows:
  `export PRE_COMMIT_CONFIG_FILE=.github/pre-commit/.pre-commit-config.yaml`

Keep in mind that anyone cloning your repository will also need to set this environment variable, or pre-commit will not be able to find the configuration file. Due to this potential complication, it is usually easier to keep the .pre-commit-config.yaml at the root of your repository.


Discover how pre-commit hooks streamline workflows, ensure code quality, and simplify collaborations using a real-world example.

Leverage Pre-Commit Hooks to Improve Your Git Workflow


While Git provides a suite of powerful tools out of the box, the true strength of this version control system lies in its flexibility and adaptability. In this blog post, we will dive into a specific aspect of Git that often goes underappreciated: customizing the git log command. By customizing your git log output, you can enable yourself to make your Git logs look exactly the way you want.

Before we get into it, let's understand the default behavior of `git log` command. By default, git log shows the commit hash, author, date, and commit message. While this is helpful, you can modify it to show more specific and visually appealing details. How?

You can do this by setting aliases in the The `.gitconfig` config file. This is where you can define global configurations and aliases.

So in order to show case some of the stuff can be done as aliases, i'll share some of my aliases the resides in my gitconfig file:

**git lg**

```bash
[alias]
    lg = log --color --graph --pretty=format:'%C(yellow)%h%Creset -%C(red)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
```

This alias provides a colorful, abbreviated commit log with a graph on the side.

![git-lg](/images/git-lg.png)

**git lol**

```bash
[alias]
    lol = log --graph --decorate --pretty=oneline --abbrev-commit --format=format:'%C(yellow)%h%C(reset)%C(red)%d%C(reset) %C(white)%s%C(reset) %C(green)(%ar)%C(reset) %C(bold blue)<%an>%C(reset)'
```

Building on the previous alias, this one presents an even more compact one-liner version of the log.

**git lola**

```bash
[alias]
    lola = !git lol --all
```

Extends the lol alias by displaying logs from all branches.

**git lgc**

```bash
[alias]
    lgc = !git lg | sed '$a\\' | grep '* ' | tac | cat -n | sed 's/^[ \t]//' | sed 's/[\t][\\*]//' | tac | less -XR
```

This is a more advanced alias that manipulates the output using sed and less to display the log entries in a structured manner with an accompanying index.

---

Looking at the lg and lol aliases, there are several formatting options used:

**_--graph:_** Displays an ASCII graph of the branch and merge history.

**_--pretty=format:'...':_** This option allows us to specify the format of the log output. Within the format string, we can use placeholders like %h (abbreviated commit hash), %an (author name), and %s (commit subject).

**_--abbrev-commit:_** This shortens the commit hash to a smaller, more readable length.

**_Color Formatting:_** Using %C(color_name) before a placeholder will change its color in the log. For instance, %C(yellow)%h%Creset will display the commit hash in yellow.

To conclude this short one, customizing Git logs is more than just a visual preference. It can drastically enhance your Git experience, helping you quickly grasp your repository's history and the relationships between commits and branches. By using the `.gitconfig` to its full potential, you can mold Git's behavior to suit your unique workflow and aesthetic preferences.


By customizing your git log output, you can make your Git logs look exactly the way you want which could make your life easier.

git Articles

All git Articles

Leverage Pre-Commit Hooks to Improve Your Git Workflow

Customizing Your Git Log Output