The easy way to keep your repos tidy.

Catch simple issues before code review using pre-commit.

Pre-commit uses git hooks in order to catch your little typos before they hit the git tree. Automatically format your code, run a linter, type check, check config files, and more.

SUPPORT ME ⭐
---------------------------------------------------

Top patrons and donors: Jameson, Laura M, Dragos C, Vahnekie, John Martin, Casey G, Pieter G, Krisztian M, Sigmanificient

BE ACTIVE IN MY COMMUNITY 😄
---------------------------------------------------

CHAPTERS
---------------------------------------------------
0:00 Intro
0:42 Git hooks
1:33 Install and use pre-commit
3:46 Favorite pre-commit hooks
4:39 After a config change
5:00 Is this safe?

[bhc]

Tried this on a python dev team. Led to team members committing less often, as each commit kicked off a small battle with the autoformatter and linter. Refactor code tickets were the worst. You comment out big chunks of functionality temporarily to keep things working through the transition, then the formatter removes all the orphaned variables/imports, which can take hours to reproduce. The sweet spot in my opinion is to enforce lint before merging a PR into master.

[DmitriyVasil]

I usually use vscode with an auto-formatting option on save. but running tests on every commit sounds interesting. as always, thanks for the video

[pedrovalois]

Nice. I normally use pre-commit with shed, but I probably need that yaml linter you showed too.

[Rizhiy]

In my experience git hooks don't really work in practice since you can't enforce them properly. You need to nag each individual developer to install them every time they clone a new repository.

What works much better is having a format check in CI and forbid merges unless all tests pass. Also, this has additional benefit of allowing developers to work at their own pace and only tidy up code when they are ready to merge.

[JakubYTb]

Two of my favorite Python YouTubers just merged (pun intended). Mr. Anthonks ftw!

[mushrafaltaf]

On point, no BS, fast and understadable. Thank you. Subscribed!

[johnrussell]

Dang! I wish I saw this video sooner! I could've used the pre-push hooks to prevent myself pushing non-rebased fixup commits.

[liesdamnlies]

Okay that’s nice and all, but nothing beats filev1, filev2, filev3, filev3_final, filev3_final2

[jonathanw]

Incredible video as usual. Just a note: there is an erroneous colon on line 28 of the yaml file, in the .src argument :) Keep up the good work, always looking forward to your videos!

[falxie_]

I like it when there are fixable errors that they're fixed during precommit

[PythonisLove]

Also, I have question regarding, how to get almost *close to pycharm* behaviour in *vscode* _(using linters, formatters, language server)_
Please recommend, or may be make a video about that?

[Kralnor]

Excellent and very concise video. Consider me a new subscriber.

[georgesmith]

Sounds like something I want to run every month or so, but once I learn from the several runs, I just don't see the point and I have to uninstall the hook. That is probably trivial, of course. But, sounds great for security - that is something you want to really check, especially on very sensitive code.

[drooten]

Would love to see a deeper presentation of this.

[ManuelBTC]

Tried this in the past, but some checks really add a great deal of friction. Maybe I need to break up my projects more or commit less often, idk.

[somebodystealsmyname]

I would rather run this things once before a PR/MR is merged than with every single commit.

[objectobject]

my goto if i have a bad commit in my remote branch: git checkout HEAD~1 && git push -f origin HEAD:<branchname> git reset --hard origin/<branchname>

[SemihTekten]

Great content, like always. But I wouldnt use pre commit auto formatter, because of two reasons:
1. It may mess with the logic/what the code tries to achieve
2. Because of #1, I need to double check after auto-formatting

If a new commit is not expensive in your organization, I’d fix these issues with isort-flake8-mypy tests with new/different commits and with more control. Because the new changes will/should only be related to formatting/typing and should not change the logic.

[BeenOrange]

Hes James, nice Video. One thing to look out for with mypy and pre-commit is that pre-commit by default will only run mypy on the changed files. This is not ideal as your changes in one file will often affect code in other files. Moreover, since pre-commit runs each hook in it's own venv, mypy can't properly typecheck your code when you use external dependencies. These issues have bitten me once or twice in the past.

There's a better way to configure the hook, but it’s a bit more complicated. There's a good blog post about it by Jared Khan, I recommend looking it up some time.

[rashidnizamuddin]

what if a dev does not run the command pre-commit install to generate hooks on local
i am titling more towards CI to run the formatter on build system