Hướng dẫn Hoàn chỉnh về Git Hooks: Cài đặt, Sử dụng, và Mẹo hay

Git hooks cho phép bạn tự động hóa các tác vụ trong quy trình làm việc bằng cách chạy script trước hoặc sau các hành động của Git như commit hay push. Chúng giúp phát hiện vấn đề sớm, áp dụng tiêu chuẩn, và thậm chí tự động sửa lỗi.

Giả sử bạn đã viết một script để áp dụng chuẩn định dạng mã. Bạn có thể thêm script đó vào một hook chạy trước khi commit. Từ nay, mỗi khi ai đó cố gắng commit, hook sẽ chạy. Nếu mã vượt qua các kiểm tra trong hook, commit sẽ được thực hiện. Nếu không, commit sẽ bị chặn.

Và không chỉ dừng lại ở việc đánh dấu vấn đề. Bạn cũng có thể tùy chỉnh script để sửa các lỗi đó trước khi commit diễn ra. Trong bài viết này, tôi sẽ trình bày mọi thứ bạn cần biết về Git hooks: chúng là gì, hook nào quan trọng, và cách triển khai hiệu quả.

Git Hooks là gì?

Git hooks tự động chạy các script tùy chỉnh khi một số hành động nhất định của Git xảy ra, như trước hoặc sau một commit, push, hay merge. Chúng được tích hợp sẵn trong Git, nên bạn không cần cài thêm thư viện bên ngoài.

Khi bạn khởi tạo một kho Git, Git tạo sẵn các hook theo mặc định. Bạn sẽ thấy chúng trong thư mục .git/hooks. Chúng có phần mở rộng .sample để ngăn chạy mặc định. Nếu muốn chạy ngay mặc định, chỉ cần bỏ phần mở rộng .sample.

Bạn có thể viết hook bằng bất kỳ ngôn ngữ script thực thi nào. Ví dụ, trong tệp pre-commit hook, bạn có thể thêm một script kiểm tra các bình luận "To-do" trong các tệp đã staged và chặn commit nếu phát hiện thấy. Tức là mỗi lần bạn commit, Git sẽ quét các bình luận bắt đầu bằng “To-do” và sẽ thất bại nếu còn tác vụ đang chờ. Tương tự, bạn có thể tạo các hook tùy chỉnh cho các hành động git khác như post-commit, pre-merge, pre-push, và nhiều hơn nữa.

Các loại Git Hooks

Trước khi đi vào ví dụ thực tế, hãy hiểu hai loại Git hooks.

Hooks phía máy khách: phân loại và ví dụ thường gặp

Hooks phía máy khách chạy trên máy cục bộ trong các thao tác Git như commit, rebase, và push. Dưới đây là một vài hook phổ biến và trường hợp sử dụng cụ thể.

• pre-commit: Chạy trước cả khi bạn gõ thông điệp commit. Dùng để áp dụng chuẩn mã, chạy kiểm thử, hoặc kiểm tra lỗi cú pháp trước khi commit. 
• prepare-commit-msg: Chạy sau khi Git tạo thông điệp commit mặc định nhưng trước khi trình soạn thông điệp mở ra. Hook này có thể chỉnh sửa hoặc thay thế thông điệp mặc định dựa trên logic script tùy chỉnh. 
• commit-msg: Hook này chạy ngay sau khi lưu thông điệp commit, nhưng trước khi Git hoàn tất commit. Đây là chốt chặn cuối cùng để áp dụng quy tắc thông điệp commit như định dạng, cấu trúc, hoặc gắn thẻ.
• post-commit: Chạy sau khi commit được tạo. Thường dùng để gửi thông báo (ví dụ gửi tin nhắn Slack sau commit) hoặc ghi log (lưu metadata commit).
• post-checkout: Chạy sau lệnh git checkout thành công. Nó kích hoạt khi bạn chuyển nhánh hoặc checkout một commit hay đường dẫn cụ thể. Có thể dùng để dựng lại phụ thuộc dự án, xóa tệp tạm, hoặc thông báo về nhánh mới.
• post-merge: Chạy sau khi merge thành công. Thường dùng để cập nhật phụ thuộc, in thông báo merge, hoặc xóa cache.
• pre-rebase: Chạy trước một thao tác rebase. Dùng để ngăn rebase các nhánh được bảo vệ, chạy test trước khi cho phép rebase, hoặc dừng rebase nếu có thay đổi chưa commit.
• pre-push: Chạy trước khi push thay đổi. Giúp ngăn push lên nhánh được bảo vệ hoặc chạy test trước khi push.
• post-rewrite: Chạy sau khi Git ghi lại (rewrite) commit thành công. Kích hoạt khi thực hiện git commit --amend (ghi lại commit cuối) hoặc git rebase (ghi lại một chuỗi commit). Dùng để cập nhật tham chiếu hoặc kích hoạt test và bước CI sau khi ghi lại.
• pre-applypatch: Được gọi bởi lệnh git am, hook này chạy sau khi một bản vá được áp dụng vào working tree nhưng trước khi tạo commit mới. Nếu kiểm tra trong hook này thất bại, nó có thể thoát với trạng thái khác 0 và ngăn patch được commit.
• post-applypatch: Git chạy cái này sau khi áp dụng patch và tạo commit. Nó không thể hủy commit nhưng phù hợp để ghi log hoặc gửi thông báo.
• applypatch-msg: Git chạy cái này trước khi git am áp dụng patch. Dùng để kiểm tra hoặc chỉnh sửa thông điệp commit được đề xuất cho patch.

Hooks phía máy chủ: phân loại và trường hợp sử dụng

Hooks phía máy chủ chạy trên máy chủ Git từ xa và kích hoạt khi xảy ra các sự kiện từ xa, như trước hoặc sau khi push vào một kho.

• pre-receive: Máy chủ chạy cái này trước khi chấp nhận một push. Bạn có thể dùng để áp dụng chuẩn mã nhất quán giữa người dùng hoặc chạy kiểm tra bảo mật trước khi chấp nhận thay đổi từ client.
• update: Trong khi pre-receive chạy một lần cho mỗi push, hook update chạy cho mỗi tham chiếu (nhánh hoặc tag) được thay đổi trong một lần push.
• post-receive: Chạy sau khi thao tác git push hoàn tất. Thường dùng để gửi thông báo, ghi log toàn diện, hoặc kích hoạt pipeline CI/CD.
• post-update: Chạy sau khi Git cập nhật tất cả tham chiếu trong một push. Bạn có thể dùng để gửi thông báo đơn giản vì, không như post-receive, nó không thể truy cập cả log cũ và mới của từng cập nhật tham chiếu.
• reference-transaction: Kích hoạt khi một giao dịch tham chiếu được chuẩn bị, commit, hoặc hủy nên có thể chạy nhiều lần. Dùng để xác thực hoặc từ chối cập nhật trên nhiều tham chiếu trong một giao dịch, hoặc để ghi log và kiểm toán thay đổi ref.
• push-to-checkout: Kích hoạt khi bạn git push vào một nhánh đang được checkout trên máy chủ từ xa. Với hook này, bạn có thể cập nhật tệp trên máy chủ sau một push, ghi log thay đổi, hoặc chặn các push không an toàn trực tiếp vào working directory.
• pre-auto-gc: Chạy ngay trước khi Git kích hoạt dọn rác tự động (garbage collection). Bạn có thể dùng để ghi nhận bắt đầu dọn rác, chặn trong lúc hệ thống bận tài nguyên, hoặc xử lý các tác vụ cần thiết trước khi dọn rác.
• proc-receive: Chạy khi lệnh git-receive-pack xử lý một push đến. Nó cập nhật tham chiếu (nhánh và tag) trong kho từ xa và báo kết quả lại cho client.

Thiết lập Git Hooks

Trong phần này, bạn sẽ tìm thấy các bước cài đặt và thiết lập git hooks. Bạn cũng sẽ thấy cách tạo hook tùy chỉnh từ đầu. 

Cơ chế cài đặt và cấu hình

Khi bạn khởi tạo một kho Git, Git tự động tạo một tập hook trong thư mục .git/hooks. Để xem, mở terminal và đi đến thư mục gốc của kho nơi bạn đã chạy git init. Từ đó, mở thư mục ẩn .git rồi thư mục con hooks. Một lệnh cd đơn giản sẽ làm tất cả cho bạn và đưa bạn vào thư mục hooks.

cd .git/hooksĐược hỗ trợ bởi

Khi vào trong, bạn sẽ thấy các hook mặc định với phần mở rộng .sample. Để bật một hook mặc định, hãy bỏ phần mở rộng .sample cho hook đó và đặt quyền thực thi.

Ví dụ, dùng lệnh dưới đây để bỏ phần mở rộng .sample khỏi hook pre-commit.

mv .git/hooks/pre-commit.sample .git/hooks/pre-commitĐược hỗ trợ bởi

Tiếp theo, cấp quyền thực thi bằng lệnh dưới đây:

chmod +x .git/hooks/pre-commitĐược hỗ trợ bởi

Vậy là xong phần chỉnh sửa và bật các hook mặc định. Để tạo hook tùy chỉnh từ đầu, làm theo các bước sau.

Để mở một tệp mới trong .git/hooks/, chạy:

nano .git/hooks/commit-msgĐược hỗ trợ bởi

Tạo script trong tệp này. Ví dụ:

 #!/bin/sh
echo "✅ Commit message hook triggered"Được hỗ trợ bởi

Lưu và thoát, rồi cấp quyền thực thi:

chmod +x .git/hooks/commit-msg Được hỗ trợ bởi

Trong ví dụ trên, mỗi khi commit được thực hiện, hook sẽ in ra thông báo " Commit message hook triggered"

Có một cách khác để thiết lập hook tùy chỉnh. Khi bạn khởi tạo một kho, Git bao gồm các hook mặc định. Bạn có thể chỉnh sửa các mặc định này bằng thư mục mẫu (template). 

Cách hoạt động: Khi bạn chạy git init, Git sao chép nội dung của thư mục mẫu toàn cục vào thư mục .git/ của kho mới, bao gồm cả hooks. Nếu bạn thêm các script hook tùy chỉnh vào thư mục mẫu toàn cục, mọi kho mới bạn tạo sẽ tự động kế thừa những hook tùy chỉnh đó.

Tạo và tùy chỉnh script hook

Trước hết, bạn cần xác định mục tiêu muốn đạt được. Là phát hiện thông điệp commit mơ hồ, ngăn push nhầm, hay xóa cache? Xác định mục tiêu ngay từ đầu rất quan trọng vì các hook khác nhau phục vụ mục đích khác nhau, và bạn cần biết dùng cái nào. 

Ví dụ, nếu bạn muốn kiểm tra kiểu thông điệp commit, bạn sẽ dùng hook commit-msg. Nếu muốn tránh một số push lên nhánh main, bạn nên dùng hook pre-push. 

Sau khi chọn hook, quyết định tiếp theo là ngôn ngữ. Trên macOS và Linux, một script Bash nhỏ (hoặc sh thuần) thường là đủ. Trên Windows, một số đội dùng PowerShell. 

Nếu repo của bạn đa ngôn ngữ, bạn có thể thích một trình thông dịch phổ biến như Python hoặc Node.js để mọi người chạy cùng một logic. Vì vậy, điều then chốt là thêm shebang (#!/bin/sh, #!/usr/bin/env python3, v.v.) ở đầu để Git biết cách thực thi.

Một ví dụ pre-commit đơn giản ngăn commit tệp .env. Điều này tránh việc đẩy nhầm khóa API nhạy cảm.

#!/bin/sh

# Block committing secrets
if git diff --cached --name-only | grep -q ".env"; then
  echo "❌ .env file detected in commit! Remove it before committing."
  exit 1
fi

exit 0Được hỗ trợ bởi

Khi muốn vô hiệu hóa hooks, cách dễ nhất là tạm thời đổi tên chúng (chuyển pre-commit thành pre-commit.off) hoặc bỏ quyền thực thi. 

Tuy nhiên, nếu bạn chỉ cần bỏ qua một lần, dùng git commit --no-verify để bỏ qua commit hooks và git push --no-verify để bỏ qua push hooks. Bạn thậm chí có thể vô hiệu hóa hooks toàn cục bằng cách trỏ Git tới một thư mục trống với git config core.hooksPath /dev/null.

Các Trường hợp Sử dụng Phổ biến và Ví dụ về Git Hooks

Git hooks đặc biệt hữu ích để tự động hóa kiểm thử, kiểm tra bảo mật, và áp dụng tiêu chuẩn chất lượng trong quy trình làm việc của bạn. 

Kịch bản tự động hóa thực tế

Áp dụng chuẩn mã hoặc linting: Hook pre-commit thường được dùng để tự động định dạng mã và phát hiện lỗi tiềm ẩn trước khi commit diễn ra.

Ví dụ, trong pre-commit dưới đây, prettier tự động xử lý định dạng và stage các thay đổi trước khi commit. Sau đó một linter có thể chạy ngay, và commit chỉ thành công nếu linting qua. Nếu thất bại, commit sẽ bị dừng.

#!/bin/sh

# Collect staged JS/TS files
FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(js|ts|tsx)$')
[ -z "$FILES" ] && exit 0

echo "Formatting with Prettier..."
npx --yes prettier --write $FILES

# Re-stage files that Prettier changed
echo "$FILES" | xargs git add

echo "Linting with ESLint..."
npx --yes eslint $FILES
STATUS=$?

if [ $STATUS -ne 0 ]; then
  echo "ESLint found issues. Fix them or commit with --no-verify if needed."
  exit $STATUS
fi

echo "Pre-commit checks passed."
exit 0Được hỗ trợ bởi

Chạy kiểm thử tự động: Bạn có thể đặt hook để chạy kiểm thử tự động trước khi push bất kỳ thay đổi nào. Ví dụ, pre-push dưới đây tự động phát hiện và chạy pytest có sẵn trong repo của bạn trước khi push.

#!/bin/sh
echo "Running tests before push..."
pytest -q
STATUS=$?
[ $STATUS -eq 0 ] || { echo "Tests failed. Push aborted."; exit $STATUS;Được hỗ trợ bởi

Tự động chặn commit dữ liệu nhạy cảm: Các tệp nhạy cảm như .env, .pem, hoặc .key thường chứa bí mật. Ví dụ pre-commit sau kiểm tra các mẫu như vậy và chặn commit nếu chứa chúng.

#!/bin/sh
set -e

STAGED=$(git diff --cached --name-only --diff-filter=ACM)

# Block dotenv and private keys
echo "$STAGED" | grep -E '\.env(\.|$)|(^|/)\.env$|\.pem$|\.key$|id_rsa$' >/dev/null 2>&1 && {
  echo "Sensitive file detected in staged changes. Remove it from the commit."
  exit 1
}Được hỗ trợ bởi

Mẹo Viết Git Hooks Hiệu quả

Dưới đây là một số mẹo tôi thấy hữu ích khi viết Git hooks. 

Giữ hook chạy nhanh

Hook chạy mỗi lần bạn kích hoạt một số hành động Git, nên hãy giữ chúng gọn nhẹ. Nếu bạn có bộ kiểm thử lớn, hãy chạy chúng trên CI thay vì trong hook cục bộ để đạt hiệu năng tốt hơn. Chạy linter, formatter, hoặc kiểm tra trên toàn bộ kho ở mọi commit sẽ làm chậm bạn, nên hãy giới hạn kiểm tra vào các tệp thực sự thay đổi.

Duy trì khả năng tương thích đa nền tảng 

Đảm bảo hook hoạt động trơn tru trên các hệ điều hành khác nhau. Dùng shebang di động, xử lý thống nhất kết thúc dòng (ưu tiên LF thay vì CRLF), và không hardcode đường dẫn tuyệt đối. 

Thay vào đó, dựa vào PATH và các script dự án cục bộ như npm run lint hoặc python -m để chạy trên nhiều môi trường.

Chiến lược gỡ lỗi

Thêm log chi tiết hoặc cờ debug (ví dụ HOOK_DEBUG=1) để truy vết cách script chạy. In chi tiết như thư mục hiện tại, nhánh, hoặc các tệp đang được stage. Điều này giúp dễ theo dõi luồng thực thi và xác định chỗ xảy ra lỗi.

Kiểm thử hook với các đầu vào khác nhau và mô phỏng kịch bản thất bại tại chỗ trước khi đẩy thay đổi. Nếu một hook chặn tiến độ ngoài ý muốn, bạn có thể tạm thời bỏ qua bằng cờ --no-verify của Git hoặc dùng biến môi trường được thiết kế để bỏ qua hook.

Để duy trì hành vi nhất quán trên các hệ điều hành, tránh lệnh đặc thù hệ điều hành và ưu tiên ngôn ngữ script di động.

Tài liệu rõ ràng

Tài liệu tốt cải thiện sự thấu hiểu trong nhóm và giúp onboarding thành viên mới dễ dàng. Duy trì một README trung tâm nêu rõ mục đích, hành vi, và cách dùng của từng hook. Bao gồm cách chạy, yêu cầu tiên quyết, xử lý sự cố, và mẹo bỏ qua. Đồng thời cung cấp hướng dẫn cài đặt/thiết lập. 

Kỹ thuật Triển khai Nâng cao và Thực tiễn Tốt nhất cho Git Hooks

Nếu bạn là người dùng nâng cao, các mẹo này có thể hữu ích:

Tối ưu hiệu năng

Để tối ưu hiệu năng trong quy trình phức tạp, giảm phụ thuộc bên ngoài bằng cách tránh thư viện nặng. Điều này giảm thời gian khởi động và các điểm lỗi. 

Cache kết quả của các tiến trình tốn tài nguyên như linting để tái sử dụng khi tệp không thay đổi. 

Nếu hook chứa nhiều kiểm tra, hãy chạy song song để tiết kiệm thời gian. Đồng thời, mô-đun hóa script hook. Tức là cấu trúc hook thành các thành phần nhỏ, tái sử dụng, chỉ thực thi phần liên quan theo ngữ cảnh.

Xâu chuỗi và điều phối hook

Dùng xâu chuỗi hook để chạy nhiều hook trong một sự kiện git. Ví dụ, trong pre-commit, bạn có thể chạy linting, rồi chạy test, sau đó định dạng mã, tất cả được xâu chuỗi. Mỗi lệnh chạy nối tiếp, và nếu bất kỳ lệnh nào thất bại (thoát với mã khác 0), các lệnh sau có thể bị bỏ qua để ngăn một commit kém chất lượng. 

Khi các tác vụ trong hook độc lập, bạn cũng có thể chạy song song để tiết kiệm thời gian. Khi đó bạn dùng điều phối để quản lý thực thi theo đúng thứ tự.

Quản lý cấu hình 

Mỗi repo có thư mục .git/hooks riêng. Nghĩa là nếu bạn muốn cùng một kiểm tra (ví dụ linting) ở nhiều dự án, bạn phải sao chép chúng ở mọi nơi. Cách tốt hơn là quản lý hook tập trung để mọi kho có thể truy cập và chạy chúng.

Bạn có thể làm điều này với một lệnh: git config --global core.hooksPath ~/.githooks. Lệnh này bảo Git tìm hook trong thư mục ~/.githooks. Bất kỳ hook nào bạn tạo ở đó sẽ được chia sẻ tự động cho tất cả các kho của bạn.

Bạn cũng có thể làm logic hook linh hoạt hơn với tệp cấu hình (JSON hoặc YAML). Thay vì hardcode logic khác nhau cho từng kho, script hook có thể đọc tệp cấu hình của kho đó và tự động áp dụng quy tắc đúng.

Thực thi có điều kiện

Trong script hook, bạn có thể thêm các điều kiện đơn giản để chỉ chạy khi phù hợp. Có thể là kiểm tra tên nhánh hiện tại, xem tệp nào thực sự thay đổi, hoặc đọc biến môi trường cho biết cần bỏ qua.

Nếu muốn kiểm soát nhiều hơn, dùng một framework như pre-commit, nơi bạn khai báo trong tệp cấu hình các hook chạy ở giai đoạn nào. Bạn cũng có thể thêm logic điều kiện, như chỉ chạy hook trên một số nhánh, bỏ qua hook bằng biến, hoặc thậm chí thêm điều kiện theo thời gian. Điều này làm script hook linh hoạt và phù hợp với quy trình thực tế.

Chiến lược cộng tác và chia sẻ 

Có hai cách bạn có thể tập trung hóa git hooks và chia sẻ giữa các kho và nhóm:

Mẫu Git (Git templates)

Khi bạn khởi tạo một kho, Git thêm một số hook mặc định dưới thư mục git/hooks. Chúng đến từ template mặc định của Git.

Để tạo hook tùy chỉnh tập trung, bạn có thể tạo một thư mục template Git, viết hook của bạn ở đó, và đặt Git toàn cục dùng thư mục mới này làm template mặc định. 

git config --global init.templateDir /path/to/hooks-templateĐược hỗ trợ bởi

Nhưng phương pháp này thiếu kiểm soát phiên bản cho hooks. Cách này đặc biệt hữu ích nếu hook của bạn ít thay đổi. Nếu bạn cập nhật hook thường xuyên và cần kiểm soát phiên bản, bạn sẽ muốn dùng cách tiếp theo.

Kho git trung tâm

Tạo một kho trung tâm riêng, có kiểm soát phiên bản, và lưu toàn bộ script hook tùy chỉnh của bạn trong kho đó, tách biệt với kho dự án. Như vậy bạn có thể cập nhật hook độc lập với mã nguồn dự án. 

Những hook này nên được tiêu chuẩn hóa, tức là tránh hardcode đường dẫn hoặc giá trị gắn với một kho duy nhất.

Thiết lập này đặc biệt hữu ích cho các nhóm, vì mọi người có thể pull cập nhật thường xuyên và đồng bộ vào dự án của họ. 

Một cách hiệu quả hơn là dùng một script thiết lập để clone kho hook trung tâm và sao chép script hook vào thư mục .git/hooks của từng dự án. Ví dụ script thiết lập: 

#!/usr/bin/env bash
set -euo pipefail

# Location of the shared hooks template repo
HOOKS_TEMPLATE_REPO="[email protected]:your-org/git-hooks-template.git"
HOOKS_TEMPLATE_DIR="$HOME/.git-hooks-template"

# Clone or update the template repo
 echo "Cloning hooks template repo..."
 git clone "$HOOKS_TEMPLATE_REPO" "$HOOKS_TEMPLATE_DIR"

# The repo where you want hooks installed
TARGET_REPO="${1:-$(pwd)}"
TARGET_HOOKS_DIR="$TARGET_REPO/.git/hooks"

# --- Copy strategy ---
echo "Copying hooks into $TARGET_HOOKS_DIR..."
cp -r "$HOOKS_TEMPLATE_DIR/"* "$TARGET_HOOKS_DIR/"

# 4. Make sure hooks are executable
chmod +x "$TARGET_HOOKS_DIR"/* || true

echo "✅ Hooks installed successfully into $TARGET_REPO"Được hỗ trợ bởi

Một lựa chọn khác là dùng symlink. Bạn có thể liên kết thư mục .git/hooks của mỗi dự án tới các script trong kho hook được kiểm soát phiên bản của bạn. Vì vậy mỗi khi bạn cập nhật kho trung tâm, các hook cũng tự động cập nhật vì symlink trỏ tới đó.

Để giữ hệ thống này đáng tin cậy, hãy thiết lập quy trình rõ ràng để duy trì hook. Thành viên nhóm nên đề xuất thay đổi hook qua pull request, chỉ merge sau khi review, và cập nhật tài liệu khi hook phát triển. 

Tích hợp Git Hooks vào Quy trình Phát triển

Git hooks đóng vai trò lớn trong tích hợp liên tục (CI). Về ngữ cảnh, CI nghĩa là hợp nhất thay đổi thường xuyên, rồi chạy build và test để phát hiện vấn đề sớm. Bằng cách kết nối hook với các công cụ CI/CD như Jenkins, GitHub Actions, hoặc GitLab CI, bạn có thể kích hoạt build, chạy test, và thậm chí tự động triển khai ứng dụng dựa trên các sự kiện của Git.

Ví dụ, một hook phía máy chủ pre-receive chạy một script tùy chỉnh trên máy chủ Git trước khi chấp nhận push. Nếu script thất bại, máy chủ sẽ từ chối push. Bạn có thể dùng điều này để kiểm tra xem bản build CI mới nhất trên nhánh đó có vượt qua hay không trước khi cho phép push. Lần chạy CI đó có thể bao gồm kiểm tra độ bao phủ mã, unit hoặc integration test, hoặc thậm chí quét bảo mật.

Hook cũng có thể tự động hóa các tác vụ triển khai. Một post-receive hook có thể kích hoạt webhook để khởi chạy pipeline CI/CD. Khi mã được merge vào main, nó sẽ tự động khởi động chu trình build → deploy → release.

Lưu ý Bảo mật và Thực tiễn Tốt nhất 

Nếu bạn duy trì hook tập trung để cộng tác dễ dàng và nguồn chân lý chung, hãy đảm bảo thư mục hook có quyền tệp an toàn để ngăn truy cập trái phép. Chỉ người dùng tin cậy mới có quyền ghi.

Bạn luôn phải xác thực các đầu vào hoặc tham số mà script hook nhận để tránh tấn công chèn mã. Ví dụ, xác thực đầu vào theo mẫu chặt chẽ như chỉ cho phép tên nhánh với chữ và số cùng dấu gạch ngang, hoặc tag khớp vMAJOR.MINOR.PATCH. 

Không bao giờ hardcode dữ liệu nhạy cảm trong script hook. Thay vào đó, dùng biến môi trường hoặc công cụ quản lý bí mật chuyên dụng để cung cấp thông tin xác thực an toàn khi chạy. Bạn có thể tích hợp các công cụ như Gitleaks với pre-commit hook để chạy quét bảo mật thông tin nhạy cảm trong các thay đổi bạn sắp commit.

Ai đó có thể chuyển hướng hook của bạn để gửi mã hoặc thông tin tới máy chủ khác. Vì vậy hãy giới hạn các miền mà hook có thể truy cập. Dùng proxy hoặc tường lửa để chặn máy chủ đích không xác định. Đồng thời, đảm bảo log của bạn không hiển thị thông tin mật trong thông điệp hiển thị. 

Kết luận

Git hooks là cách mạnh mẽ để tự động hóa tác vụ và áp dụng tiêu chuẩn trực tiếp trong quy trình phát triển của bạn. Chúng giúp từ định dạng mã, kiểm thử đến triển khai và kiểm tra bảo mật.

Sử dụng tốt, bạn sẽ giảm lỗi, tiết kiệm thời gian, và làm việc nhóm trơn tru hơn.

Bắt đầu với các kiểm tra pre-commit đơn giản, rồi thử nghiệm các thiết lập nâng cao như điều phối, quản lý tập trung, hoặc tích hợp CI/CD. Nếu bạn là người dùng Git và muốn nâng cao kỹ năng, hãy xem khóa học Git nâng cao này.