Which statement correctly describes the main difference between client-side and server-side Git hooks?
Think about where the hooks execute: on your computer or on the remote server.
Client-side hooks run on the developer's local machine to check or modify commits before they are made or pushed. Server-side hooks run on the remote repository server to enforce rules when code is pushed or received.
Given this simple pre-commit hook script in .git/hooks/pre-commit that prevents commits with TODO comments:
#!/bin/sh grep -q 'TODO' **/*.py && echo 'Commit blocked: TODO found' && exit 1 || exit 0
What will happen if you try to commit a Python file containing a TODO comment?
Consider what grep -q does and the exit codes in shell scripts.
The script searches for 'TODO' in Python files. If found, it prints the message and exits with code 1, blocking the commit. Otherwise, it exits 0 allowing the commit.
You want to prevent anyone from pushing directly to the main branch on the remote Git server. Which server-side hook should you configure and what should it do?
Think about which server-side hook runs before accepting pushed commits.
The pre-receive hook runs on the server before accepting any pushed refs. It can reject pushes to specific branches like main by checking the ref names.
You created a commit-msg hook script in .git/hooks/ to validate commit messages, but it does not run when you commit. What is the most likely reason?
Check file permissions for scripts in .git/hooks.
Git requires hook scripts to have execute permissions to run. Without it, the hook is ignored silently.
What is the best way to ensure all developers on a team use the same Git hooks without manually copying scripts into each local .git/hooks directory?
Think about how to version control hooks and configure Git to find them.
Git does not track .git/hooks in the repository. Storing hooks in a versioned directory and setting core.hooksPath lets all developers share hooks easily.