Bird
Raised Fist0
Gitdevops~5 mins

Client-side vs server-side hooks in Git - Quick Revision & Key Differences

Choose your learning style10 modes available
Recall & Review
beginner
What is a client-side hook in Git?
A client-side hook is a script that runs on your local computer before or after certain Git actions, like committing or merging. It helps you check or change things before sending changes to the server.
Click to reveal answer
beginner
What is a server-side hook in Git?
A server-side hook is a script that runs on the Git server when someone pushes changes. It can accept or reject changes, enforce rules, or trigger other actions on the server.
Click to reveal answer
intermediate
Name one example of a client-side hook and its purpose.
The pre-commit hook runs before a commit is saved. It can check code style or run tests to prevent bad commits.
Click to reveal answer
intermediate
Name one example of a server-side hook and its purpose.
The pre-receive hook runs on the server before accepting pushed changes. It can reject pushes that don't meet rules, like missing tests or wrong branch.
Click to reveal answer
beginner
What is a key difference between client-side and server-side hooks?
Client-side hooks run on your computer before you send changes. Server-side hooks run on the server after you push changes. Client-side hooks help you catch problems early; server-side hooks enforce rules for everyone.
Click to reveal answer
Where does a Git client-side hook run?
AOn your local computer
BOn the Git server
CIn the cloud
DIn the browser
Which hook can reject a push on the server?
Apre-commit
Bpost-commit
Cpost-checkout
Dpre-receive
What is a common use of a client-side pre-commit hook?
ASend email notifications
BRun tests before commit
CDeploy code to production
DBackup the repository
Which hook type helps enforce rules for all users pushing to a repository?
AServer-side hooks
BClient-side hooks
CLocal hooks
DPost-commit hooks
When does a server-side post-receive hook run?
ABefore a commit is made locally
BBefore a push is sent
CAfter a push is accepted on the server
DWhen cloning a repository
Explain the difference between client-side and server-side Git hooks and give one example of each.
Think about where the hook runs and what it controls.
You got /4 concepts.
    Describe a scenario where using a server-side hook is better than a client-side hook.
    Consider control and security for a shared repository.
    You got /4 concepts.

      Practice

      (1/5)
      1. Which of the following best describes a client-side Git hook?
      easy
      A. A Git command to clone repositories.
      B. A script that runs on the Git server to control repository access.
      C. A tool to merge branches automatically on the server.
      D. A script that runs on your local machine before or after Git actions like commit or push.

      Solution

      1. Step 1: Understand client-side hooks context

        Client-side hooks run on your local computer and trigger before or after Git commands like commit or push.
      2. Step 2: Differentiate from server-side hooks

        Server-side hooks run on the Git server to enforce rules for all users, unlike client-side hooks which are local.
      3. Final Answer:

        A script that runs on your local machine before or after Git actions like commit or push. -> Option D
      4. Quick Check:

        Client-side hook = local script [OK]
      Hint: Client-side hooks run locally before/after Git commands [OK]
      Common Mistakes:
      • Confusing client-side hooks with server-side hooks
      • Thinking hooks run only on the server
      • Assuming hooks are Git commands
      2. Which of the following is the correct location to place a client-side pre-commit hook script in a Git repository?
      easy
      A. /usr/local/git/hooks/pre-commit
      B. .git/hooks/server-pre-commit
      C. .git/hooks/pre-commit
      D. .git/pre-commit

      Solution

      1. Step 1: Identify the standard hooks directory

        Git client-side hooks are stored inside the .git/hooks directory of the local repository.
      2. Step 2: Confirm the correct hook filename

        The pre-commit hook script must be named exactly 'pre-commit' inside .git/hooks.
      3. Final Answer:

        .git/hooks/pre-commit -> Option C
      4. Quick Check:

        Client-side hooks live in .git/hooks [OK]
      Hint: Client-side hooks go in .git/hooks folder [OK]
      Common Mistakes:
      • Placing hooks outside the .git directory
      • Using wrong filenames for hooks
      • Confusing server-side hook locations
      3. Given this server-side hook script named pre-receive on the Git server:
      #!/bin/sh
      while read oldrev newrev refname
       do
         if [ "$refname" = "refs/heads/main" ]; then
           echo "Pushes to main branch are not allowed."
           exit 1
         fi
       done
      exit 0
      What will happen if a user tries to push commits to the main branch?
      medium
      A. The push will be rejected with the message 'Pushes to main branch are not allowed.'
      B. The push will succeed without any message.
      C. The push will be accepted but with a warning.
      D. The server will crash due to a syntax error.

      Solution

      1. Step 1: Analyze the pre-receive hook logic

        The script reads each ref being pushed. If the ref is 'refs/heads/main', it prints a message and exits with status 1, which rejects the push.
      2. Step 2: Understand Git hook exit codes

        Exiting with 1 means failure, so Git rejects the push and shows the message to the user.
      3. Final Answer:

        The push will be rejected with the message 'Pushes to main branch are not allowed.' -> Option A
      4. Quick Check:

        Exit 1 in server hook rejects push [OK]
      Hint: Exit code 1 in server hook blocks push [OK]
      Common Mistakes:
      • Assuming push succeeds despite exit 1
      • Confusing client-side and server-side hook effects
      • Ignoring the printed message
      4. You wrote a client-side pre-commit hook script but it does not run when you commit. What is the most likely reason?
      medium
      A. The script is placed in the wrong directory on the server.
      B. The script file is not executable.
      C. Git does not support pre-commit hooks.
      D. You forgot to push the hook to the remote repository.

      Solution

      1. Step 1: Check script permissions

        Client-side hooks must be executable files. If not, Git will ignore them silently.
      2. Step 2: Verify hook location and Git support

        The hook must be in .git/hooks locally. Git supports pre-commit hooks, and pushing hooks to remote does not affect local hooks.
      3. Final Answer:

        The script file is not executable. -> Option B
      4. Quick Check:

        Hooks must be executable to run [OK]
      Hint: Make hook scripts executable with chmod +x [OK]
      Common Mistakes:
      • Placing hooks on the server for client-side use
      • Thinking Git lacks pre-commit hooks
      • Expecting hooks to transfer via git push
      5. You want to enforce that all commits pushed to the shared repository have a signed commit message. Which hook setup is best to ensure this rule is always checked regardless of the user's local setup?
      hard
      A. Implement a server-side pre-receive hook that rejects unsigned commits.
      B. Ask each developer to add a client-side commit-msg hook to check signatures.
      C. Use a client-side pre-push hook to warn about unsigned commits.
      D. Rely on GitHub or GitLab UI to manually check commit signatures.

      Solution

      1. Step 1: Understand enforcement scope

        Client-side hooks depend on each user's setup and can be bypassed or missing.
      2. Step 2: Use server-side hooks for mandatory checks

        Server-side hooks run on the shared repository and can reject pushes that don't meet rules, ensuring enforcement for all users.
      3. Final Answer:

        Implement a server-side pre-receive hook that rejects unsigned commits. -> Option A
      4. Quick Check:

        Server hooks enforce rules for all pushes [OK]
      Hint: Use server-side hooks to enforce rules for all users [OK]
      Common Mistakes:
      • Relying only on client-side hooks for enforcement
      • Assuming UI checks block pushes automatically
      • Ignoring that client hooks can be disabled
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard