Sunucu Tarafı Git Kancaları

In the previous lesson, we learned about client-side Git hooks. Now, let's explore server-side hooks, which operate on the Git server itself.

These hooks are powerful tools for enforcing repository-wide policies and automating tasks before or after changes are accepted into the central repository.

The key difference between client-side and server-side hooks is where they run:

• Client-side hooks: Run on your local machine before actions like committing or pushing. They help enforce local best practices.
• Server-side hooks: Run on the central Git server after you push changes, but before they're fully integrated. They ensure repository-wide rules are met by everyone.

Server-side hooks provide a stronger guarantee that rules are followed by all contributors.

Server-side hooks reside in the hooks directory of your bare repository on the server.

A bare repository is one that doesn't have a working directory – it only contains the Git metadata. When you push to a remote, you're pushing to a bare repository.

Just like client-side hooks, they are executable scripts that Git runs at specific points in the workflow.

The pre-receive hook is one of the most commonly used server-side hooks. It executes once per push, before any references (like branches or tags) are updated.

It receives a list of all references being pushed and their old/new commit IDs. If this script exits with a non-zero status, the entire push is rejected, and no references are updated.

This makes it ideal for enforcing global policies.

The pre-receive hook is perfect for:

• Enforcing branch naming conventions: E.g., all new branches must start with "feature/", "bugfix/", etc.
• Validating commit messages: Ensuring every commit message includes a ticket ID or follows a specific format.
• Preventing pushes to protected branches: Blocking direct pushes to main or develop.
• Checking code for sensitive information: Basic credential scanning.

Here's a conceptual example of a pre-receive script that prevents direct pushes to the main branch. If someone tries to push to main, the push will be rejected.

This script would be placed as pre-receive in the server's bare repository hooks directory and made executable.

The update hook is similar to pre-receive but runs once for each reference being updated by a push.

It takes three arguments: the name of the reference, the old object name, and the new object name. If any update script exits with a non-zero status, only that specific reference update is rejected.

This allows for more granular control over individual branch updates.

The update hook is useful for:

• Enforcing fast-forward merges: Preventing non-fast-forward pushes to specific branches, ensuring a linear history.
• Implementing fine-grained access control: Allowing certain users to push to specific branches only.
• Logging updates: Recording every branch update for auditing purposes.
• Preventing force pushes: Ensuring history isn't rewritten on critical branches.

To implement server-side hooks:

1. Access the server: You need SSH access or similar to the Git server's repository.
2. Locate the hooks directory: Navigate to the .git/hooks directory within your bare repository.
3. Create/Modify scripts: Write your hook script (e.g., pre-receive or update).
4. Make executable: Ensure the script has execute permissions (e.g., chmod +x pre-receive).

Remember, these changes affect everyone interacting with that repository.

When working with server-side hooks:

• Keep them simple: Complex logic can be hard to debug and maintain.
• Version control hooks: Consider storing your hook scripts in a separate repository and deploying them to your Git servers for consistency.
• Test thoroughly: Ensure your hooks don't accidentally block legitimate workflows.
• Consider performance: Hooks run on every push, so avoid resource-intensive operations.

They are powerful, so use them wisely!

You've explored the power of server-side Git hooks! We learned:

• Server-side hooks enforce policies on the central Git server.
• pre-receive runs once per push, good for global checks.
• update runs once per reference, good for granular control.
• Implementing them involves placing executable scripts in the bare repository's hooks directory.

These hooks are crucial for maintaining code quality and workflow consistency in team environments. Keep practicing!