Introduction

Sometimes you want extra work to happen after git fetch or git pull, such as regenerating files, running tests, or refreshing dependencies. The first thing to know is that Git does not provide a standard built-in post-fetch hook.

That means the answer depends on which event you actually care about. If you need something after a merge caused by git pull, post-merge may help. If you need something after every fetch, you usually need a wrapper command, alias, or external script.

There Is No Standard post-fetch Hook

Git has many hooks, but a standard post-fetch hook is not one of them. That matters because many blog posts imply otherwise.

So if your requirement is “run a command after every fetch,” the usual options are:

• create a shell alias or wrapper
• use a custom script instead of calling git fetch directly
• hook into a later event such as post-merge if git pull is really the event you care about

Understanding that limitation prevents a lot of wasted time looking for a hook name that Git simply does not implement.

Use post-merge for Pulls That Merge

A traditional git pull often performs fetch followed by merge. If your command should run after the merge step completes, post-merge is the right hook.

Create .git/hooks/post-merge:

#!/usr/bin/env bash

./scripts/after-pull.sh

Make it executable:

chmod +x .git/hooks/post-merge

Now the script runs after merges, including merge-based pulls.

Important Limitation of post-merge

post-merge only helps when a merge actually happens. It does not fire for a plain git fetch, and it does not represent every possible git pull outcome. For example, if your workflow uses rebase instead of merge, you need a different event strategy.

That is why many teams prefer an explicit wrapper command instead of relying on hooks tied to only one flavor of pull behavior.

Wrapper Script for Fetch or Pull

A wrapper script is often the cleanest and most predictable answer.

1#!/usr/bin/env bash
2set -e
3
4git fetch "$@"
5./scripts/after-sync.sh

Or for pull:

1#!/usr/bin/env bash
2set -e
3
4git pull "$@"
5./scripts/after-sync.sh

This has two advantages:

• you control exactly when the follow-up command runs
• you can decide whether it should run only on success

With set -e, the follow-up command does not run if the Git command fails.

Using a Git Alias

If you want a convenient command inside Git itself, an alias can work.

git config --global alias.pull-and-build '!f() { git pull "$@" && make; }; f'

Then run:

git pull-and-build

This is not a real hook, but it is a useful workflow shortcut when the action is local and personal.

Shared-Team Considerations

Git hooks are not cloned with the repository by default. That means if you place logic under .git/hooks, every clone needs the hook installed separately.

If the follow-up command is important for the team rather than just for one developer, a wrapper script committed into the repository is often easier to share and document.

Examples:

• './scripts/update-and-build.sh'
• 'make sync'
• 'just sync'

Those approaches are explicit and travel with the repository.

Common Pitfalls

One common mistake is searching for a post-fetch hook and assuming Git must support it. Standard Git does not.

Another issue is relying on post-merge when the actual workflow uses rebase-based pulls. In that case, your command may not run when you expect.

It is also easy to hide too much important logic inside local hooks. Hooks can be useful, but because they are local to each clone, they are not a reliable way to enforce team-wide workflow requirements.

Finally, do not run expensive follow-up commands automatically unless they are truly necessary. An overly heavy hook or wrapper can make everyday version-control operations frustrating.

Summary

• Git does not provide a standard post-fetch hook.
• For merge-based git pull, post-merge can be a useful follow-up hook.
• For git fetch, or for fully predictable behavior, a wrapper script or alias is usually the best solution.
• Hooks are local to a clone, so they are weak for team-wide enforcement.
• Choose the trigger based on the actual event you care about: fetch completion, merge completion, or a custom workflow command.