Git Hook Ritual: Summon a Charm on Every Push

A git hook ritual is a script that runs automatically when you push, so a small, deliberate moment attaches itself to a command you already type every day. You wire a pre-push hook to trigger a cue, a chime or an on-screen charm, and the ritual happens without you having to remember it.

Most people treat git hooks as chores for linting and formatting. They are also the most reliable place to hang a human habit, because they fire on an event you cannot skip.

Why build a git hook ritual?

The hardest part of any ritual is remembering to do it. Willpower is unreliable at 6pm on a Friday, which is exactly when a rushed push is most likely to hurt.

A hook removes the memory problem entirely. The command itself becomes the cue, so you cannot push without the moment firing, and the ritual runs precisely when it matters most.

There is a second benefit. A pre-push hook runs before the push completes, which gives you a real beat to reconsider, the same beat to reconsider that a good ritual for shipping code is built around.

There is a third, quieter benefit that people miss. Because the hook lives in the repository, the ritual is tied to the work rather than to your mood, so it happens on the bad days as faithfully as the good ones.

How do you write a pre-push hook?

Git looks for executable scripts in your repository's .git/hooks directory, and the one that fires on push is named pre-push. Creating it takes about a minute.

From the root of your repository, create the file and make it executable.

cat > .git/hooks/pre-push <<'EOF'
#!/bin/sh
# A ritual, not a gate: mark the moment, then let the push run.
echo "Pausing before push. Read the diff you are about to ship."
open "bookmyluck://bless"   # summon the charm on your Mac
sleep 1                     # a one-second beat to reconsider
exit 0                      # 0 = allow the push to continue
EOF
chmod +x .git/hooks/pre-push

The important line for the ritual is the open call. On a Mac, open followed by a URL scheme hands the request to whichever app registered that scheme, which is how a script can reach a menu-bar app without any plugin.

The exit 0 at the end matters. It tells git the hook approved the push, so the ritual never accidentally becomes a blocker you have to fight later when you are in a hurry.

You can test the hook without pushing anything real. Run .git/hooks/pre-push directly in your terminal and watch the charm come forward; if it does, the wiring is correct and the next genuine push will behave the same way.

A word on what the hook does not do. It is not a security control, a lint step, or a stand-in for continuous integration, and it should not grow into one. Those jobs belong in your test suite and your pipeline, where they run for everyone regardless of which machine pushed. The ritual is a human layer sitting on top of those, aimed at the person, not the code, and keeping it that small is what lets it survive for years without becoming a maintenance burden of its own.

Wiring the charm to the push

The bookmyluck://bless line above works because Book My Luck registers a bookmyluck:// URL scheme on your Mac. That scheme is the bridge between your terminal and the charm hanging from the top of your screen.

When the hook runs, the charm comes forward, performs its small ritual, and settles back, all while your push proceeds. Everything under the charm still clicks through, so it never interrupts the terminal or your editor.

For a push, the ghanta suits the moment. It is the Indian temple bell, and its ritual is to ring, a clean sound that says a new thing is beginning. I ring the ghanta before a release, and the sound does more to settle me than any dashboard.

Here is the honest part. The bell does not protect the deploy. A charm works the way a pre-game ritual works: it marks the moment, steadies your hands, and gives you a story, and it makes no promise about whether the build is green.

Hooks versus other ways to trigger the ritual

The git hook is one route. Depending on how you work, another trigger may fit your day better, and you can mix them freely.

The pre-push hook

• Fires on: every git push from that repository.
• Best for: engineers who ship straight from git and want the cue tied to the command.
• Setup: one script in .git/hooks, about a minute.
• Reach: local to the repo, unless you use a shared hooksPath.

The URL scheme by hand

• Fires on: any script or alias that calls open "bookmyluck://bless".
• Best for: people whose deploy is a Makefile target or a CI-triggering command, not a raw push.
• Setup: add the line to your existing script.
• Reach: anywhere you can run a shell command.

The keyboard hotkey

• Fires on: pressing the bless hotkey, ⌥⌘B by default.
• Best for: moments that are not deploys, like starting a hard task.
• Setup: none; the hotkey exists out of the box.
• Reach: system-wide.

If your deploy is not a plain git push, the URL scheme route is more flexible. The same bookmyluck:// scheme can be driven from a Mac Shortcut, so you can attach the ritual to almost any workflow you already have.

Many teams end up using two at once: the hook for everyday pushes, and a hotkey for the moments that are not code at all. The point is that one scheme covers all of them, so you learn it once.

Making it stick without making it heavy

The failure mode of a scripted ritual is over-engineering it. Keep the hook to the fewest lines that produce a clear cue, and resist adding checks that belong in your actual test suite.

A git hook ritual only works if it stays lean. Anchor the habit to the command and nothing else. This is the same principle behind any lasting desk ritual: tie the new behaviour to a fixed event rather than to a decision you have to make each time.

If you deploy from more than one repository, copy the same hook into each so the ritual feels identical everywhere. Consistency is what turns a script into a habit, and a habit is what a wider deploy ritual is really made of.

One caution on trust. The moment the ritual starts feeling like a safeguard, step back and remind yourself that the safeguards are your tests, your review, and your rollback plan. The charm and the bell are there to steady the person pressing enter, nothing more.

Book My Luck is a one-time purchase, no subscription, if you want the on-screen charm the hook summons. The pricing is a single payment for the Mac you install it on, and the URL scheme works the same whether you drive it from git, a Shortcut, or the keyboard.

FAQ

What is a git hook ritual?

It is a small script, usually a pre-push hook, that fires a ritual cue automatically when you run a git command. The cue can be a printed line, a chime, or an on-screen charm that marks the moment before the push completes.

Does a pre-push hook block my push?

Only if the script exits with a non-zero status. Used as a ritual it ends with exit 0, so it marks the moment and lets the push continue normally.

How does a script trigger a menu-bar charm?

On a Mac, running open "bookmyluck://bless" hands the request to the app that registered the bookmyluck:// URL scheme. That is how a terminal command can reach a menu-bar app without any plugin.

Will teammates get the ritual automatically?

Not from .git/hooks, which is local and uncommitted. Set core.hooksPath to a tracked folder like .githooks and commit the script if you want it to travel with the repository.

Does the charm make my deploy safer?

No. It marks the moment and steadies you, which can reduce careless autopilot pushes, but it makes no promise about the build. Your tests, reviews, and rollback plan are the real safeguards.

Which charm works best for a push?

The ghanta, the Indian temple bell, fits well because its ritual is a clean ring that signals a beginning. Any charm works; choose the one whose story matches the moment for you.