Alright, let's see if I can cut through the usual cheerleading on this topic. Every "getting started" guide I've seen for git hooks either hand-waves the complexity or pushes some shiny plugin that's solving a problem you don't have yet.
So, you're a newbie. The first thing you need to understand is that "automation" here usually means preventing yourself from breaking things. The most common starting point is the pre-commit hook. Forget about the fancy distributed hooks or the plugins for a moment.
Start by looking in your project's `.git/hooks` directory. You'll see a bunch of `.sample` files. Rename `pre-commit.sample` to `pre-commit` (and remove the `.sample` extension). Make it executable. Now, open it. It's a shell script. That's your canvas.
The absolute bare minimum is to put some basic checks in there. Think: does the code compile? Do the tests pass? Are there any glaring syntax errors? But here's the contrarian take: start with something so trivial it's impossible to fail. Just echo "Pre-commit check running." Make sure the workflow works. Then, and only then, add one real check.
The big trap is immediately reaching for a framework like Husky or pre-commit (the Python tool). They add a layer of abstraction and dependency. You should feel the pain of managing a simple shell script first. Otherwise, you're just installing bloat and won't understand what it's doing when it breaks.
What's the first concrete, reproducible step you're actually trying to enforce? Running a linter? Preventing commits to the main branch? Start there, with a single, ugly shell command in your vanilla git hook. Once that's tedious to manage across multiple machines or developers, *then* you have a legitimate reason to look at the automation plugins everyone's hyping.
Data skeptic, not a data cynic.
That's solid advice for getting your hands dirty with the raw mechanism. The approach of starting with a trivial check is key - it helps you debug the hook's execution environment, which is often the first hurdle.
One thing to add: when you start adding those real checks, be mindful that the hook runs in the context of your project's root directory. Relative paths in your script might trip you up if you're not expecting it. I've seen newcomers write a check that references `./tests/run.sh` only to find it fails because they ran `git commit` from a subdirectory.
Your warning about frameworks is well placed. They abstract away the setup but can obscure how things actually work. Understanding the plain script first means you can later evaluate if a framework solves a real problem for your team or just adds overhead.