Git Hooks: We’re Not Using Them Enough!

In this video, I’ll explore Git hooks and demonstrate how to create a custom Python script to enhance your development workflow.

🎓 Courses:

👍 If you enjoyed this content, give this video a like. If you want to watch more of my upcoming videos, consider subscribing to my channel!

Social channels:

👀 Code reviewers:
- Yoriz
- Ryan Laursen
- Dale Hagglund
- Kit Hygh
- Alexander Milden
- Bean

🔖 Chapters:
0:00 Intro
0:32 What are git hooks?
1:02 pre-commit hook
2:11 Creating custom Python Git hook
2:56 Why should we use this?
3:54 Outro

#arjancodes #softwaredesign #python

DISCLAIMER - The links in this description might be affiliate links. If you purchase a product or service through one of those links, I may receive a small commission. There is no additional charge to you. Thanks for supporting my channel so I can continue to provide you with free content each week!

[FlorianHolzner]

Pretty much every Python project of mine has pre-commit configured, with autoformatting, linting, and if possible type checking as pre-commit hooks. In most projects we also run poetry-check if we use poetry. It's just such a neat way to keep your code consistent and always neat.

[holographictheory]

I usually use them to apply linters! Black, ruff, and isort, specifically. Then i usually have a CI check that runs the same pre-commit hook to make sure PR's are linted. However, if someone is committing unlinted code, I've had a lot of trouble with people making relative branches from the unlinted branch and then failing CI because of the other branch.

[AloisMahdal]

2:20 the right way to pass arguments in shell is `"$@"`. `$*` will trigger all sorts of replacements including (but not limited to!) splitting argument on space. this can get you into lots of trouble depending on what is actually passed. (Without consulting git and shell docs, I'm afraid one can't really rule out even things like remote code execution -- imagine commit message was passed which contained `;` or `&` which starts new command...)

...and in case someone wonders, `"$*"` won't fix it, since it will weld all arguments into one. `$*` is almost never really useful.

With the "magic at-sign" in `"$@"`, on the other hand, it will actually resolve to same number of arguments (zero to any number) as is passed, and the quoting will be interpreted as if you quoted every argument separately.

[tikendraw]

These Tuesday tips are good. But it only touches the subject, but your deep dive videos actually helps to know concepts and underlying workings more.

[virtualraider]

I use them to enforce the contents of certain files. For example, we use an alternate repo store instead of pip, so I make sure that requirements.txt contains --extra-index-url at the top of the file plus some other stuff. And the usual checks: black, isort, flake8, plus things like pyupgrade to make sure we're using appropriately pythonic features
It's super useful to maintain consistency across repos

[sshmoothie]

I use pre-commit hooks mostly to apply formatting (black, isort), and linting (flake8).

[mrcturbor]

Used the hooks to check with a DB on the network if files should be set read-only, thus allowing emulation of the checkout behavior of a pre-git version system. This was needed since labview altered the file even if no source was changed (it stored the sources and bytecode and linkinfo in the same file. The last one changed at each run!)

[danielpaurat]

I use it for linting with black. A collegue of mine uses git-hooks to strip notebooks before committing. I however like to keep the notebooks output, as I use them to document my exploration.

[murtadha]

This is actually very useful to know, thanks!

[justinsmith]

Please can you do a getting started with git in a similar format to your tutorials using poetry because those were brilliant!

[NasserAbdou]

I use pre-commit since 2 years for code quality

There are some pre-commit extensions that execute flake, linters, etc ...

We used it also for commit naming conventions

[adityamathur]

One of the use we do in our project is to use pre-commit to enable code formatting (black formatter)

[sergioamador]

It gives me an idea to make a pre-commit hook to just concatenate as a prefix to the commit message the ticket ID of the ticket I'm working on.
Since the project I'm working for has a server side hook that rejects pushes of any commits that in their messages do not contain a ticket ID pattern, this is how we keep traceability between
This is just to avoid having to write the ticket ID that I don't remember every time I make a commit.

[stainomatic]

I use it to run Black and iSort. I stick to formatting for git hooks.

[richardnpaul_mob]

Yup, using pre-commit and the pre-commit project and a large number of code formatters and linters to ensure code consistency and quality across teams. You shouldn't have one dev commit to a file and then another dev only resave the file in their editor and end up with changes (for example a dev always ensures that a file ends with a new line and doesn't allow for trailing whitespace can end up in this situation if the previous dev's editor allowed for such things).
I also recommend adding cspell for checking functional correctness in languages like yaml where mis-spellings can be syntactically correct but not functionally correct (I've given talks on this in the past 😅)

[kwik]

I have offloaded the linting to my CI/CD Pipeline, as I prefer being able to quickly commit before I leave. However, I do have a pre-commit hook that checks if I am not committing my ansible-vault unencrypted after changing the variables. Just a small safeguard to avoid silly mistakes.

[izzikora]

I'm confused when you did git commit it had the arguments '-m' and the message but the script said it had no arguments

[nickeldan]

Same as everyone else it seems. I just use pre-commit to run black, mypy, flake8, pytest, etc.

[FlisB]

I have a client that doesn't know how to use git. I am sometimes worried he doesn't update the scripts I send him. I used git pre-commit hook to save the hash of the previous commit to file and now it will be printed and logged every-time he runs the file so I will be sure he is up to date.

[shanedonlon]

I use 2 so far.

Commit msg hook to ensure the message starts with feat fix etc and has a character limit.

Pre push hook to double check I'm not pushing up any debug code eg. Print / console.log statements.