Common Git Hooks

Before diving into specific hook types, we need to clarify the core concept of "Preload" or more accurately, "Git Hook". Git hooks are a suite of tools that allow users to write automated scripts for specific Git events. They essentially consist of small programs that run automatically when an executor triggers a particular operation. These hooks play the role of "gatekeepers" in critical workflows such as code commits and branch merges, capable of validating or enforcing rules before actual changes enter the repository.

Git Hooks fall into two categories:

  • Client-side Hooks: Execute on the local computer to prevent developers from pushing non-compliant code to remote repositories. For example .git/hooks/pre-commit.
  • Server-side Hooks: Run on a Git server or hosting platform (such as GitHub, GitLab) and are typically triggered when a user attempts to push.

By configuring these hooks, teams can establish unified development standards, reduce human errors, and improve code quality.

Core Application Scenarios and Common Types

While theoretically hook scripts can be written for any event, the following types of Hooks are most commonly used in practical engineering practice and offer the greatest value:

1. Pre-commit

This is the most basic client-side hook. It triggers when a developer runs the git commit command. Its primary function is to intercept code modifications that do not comply with rules. Common application scenarios include checking file formats, ensuring all files are staged, or executing simple static analysis tools (such as ShellCheck).

2. Pre-push

Also existing as a client-side hook but runs on the developer's local machine. It triggers when a user prepares to push changes to a remote repository. It is typically used to verify if code has passed CI/CD pipelines, check for unmerged conflicts or unresolved warnings, thereby avoiding invalid or destructive commits reaching production environments.

3. Pre-receive

This is one of the most important server-side hooks. It triggers when a user attempts to push changes to a remote repository. It can enforce team-level rules, such as: rejecting code containing sensitive information; requiring all Pull Requests to pass automated tests before merging, etc.

How to Configure and Use Git Hooks

To enable or use these features, one must first understand the basic creation and activation process. The configuration file for Git hooks is located in the .git/hooks/ directory. Here are the specific steps:

  1. Write Scripts
    Create a script with executable permissions (e.g., pre-commit.sh) and write your required logic code within it. Ensure to use shebang (#!/bin/bash) at the beginning so that the system can identify the interpreter.

  2. Place Files
    Move the generated scripts into the .git/hooks/ directory and name them corresponding to the event names (e.g., pre-commit). Note: If this directory is empty, Git will automatically create it; otherwise, you need to manually move or copy existing hooks to overwrite them.

  3. Set Permissions
    Since Git only allows executing specific types of script files as hooks by default, these files must be given executable permissions. Run the following command in a Linux/macOS terminal:

    chmod +x .git/hooks/pre-commit.sh

  4. Activate and Test
    Once configured correctly with proper permissions, Git will automatically call your script upon triggering the corresponding event next time. You can immediately verify if the hook is working by attempting to commit a file containing violating content.

Best Practices and Maintenance Recommendations

While powerful, Git Hooks can hinder development efficiency or introduce performance bottlenecks if misused. Here are several key best practices:

  • Keep Them Lightweight
    Hooks should be as simple and fast as possible. Avoid running time-consuming compilation tasks or complex database queries in pre-commit, as this will significantly slow down the local workflow speed. Heavy validation should be moved to CI/CD pipelines instead.

  • Provide Clear Error Messages
    When a hook blocks a commit, it must return clear and useful reasons explaining why (e.g., "Detected uncompressed images") rather than simply displaying "Operation rejected". This helps developers quickly locate and fix issues.

  • Distinguish Between Client-side and Server-side Logic
    pre-commit is suitable for lightweight format checking and basic rule validation; complex business rules, security scanning, and integration tests should be executed in server-side hooks or CI/CD pipelines to ensure consistency across all team members' local environments without being affected.

By configuring and using Git Hooks reasonably, development teams can build a more robust, standardized, and efficient collaboration system, ensuring code quality is guaranteed before every line of commit.