Cách sử dụng Git Hooks để tự động hóa các tác vụ phát triển và triển khai

Reading Time: 14 minutes

Hệ thống quản lý phiên bản (version control) đã trở thành một yếu tố không thể thiếu trong phát triển phần mềm hiện đại. Nó cho phép dự án theo dõi thay đổi một cách an toàn và hỗ trợ quay lui (reversion), kiểm tra tính toàn vẹn (integrity checking) cũng như hợp tác giữa nhiều người, cùng nhiều lợi ích khác.

Tuy nhiên, liệu bạn đã bao giờ nghĩ đến việc tự động hóa các tác vụ lặp đi lặp lại trong quy trình phát triển của mình, từ việc kiểm tra tiêu chuẩn mã hóa đến triển khai ứng dụng, chỉ với một cú commit hay push?

Trong bài viết này, chúng ta sẽ cùng khám phá ý tưởng về Git Hooks và tìm hiểu cách triển khai mã để tự động hóa các tác vụ trong môi trường độc đáo của riêng bạn. Mặc dù bài viết này sử dụng máy chủ Ubuntu 20.04 làm ví dụ, nhưng bất kỳ hệ thống nào có thể chạy Git đều có thể áp dụng tương tự.

Chuẩn bị

Trước khi bắt đầu, bạn cần đảm bảo những điều sau:

• Cài đặt Git trên máy chủ của mình.
• Bạn nên làm quen với cách sử dụng Git nói chung.
• Bạn cần hiểu rõ với các khái niệm về Git và Git Hooks.

Khi bạn đã hoàn thành các yêu cầu trên, chúng ta hãy tiếp tục.

Ý tưởng cơ bản về Git Hooks

Git Hooks là một khái niệm khá đơn giản được triển khai để giải quyết một nhu cầu thực tế. Khi phát triển phần mềm trong một dự án chia sẻ việc duy trì các tiêu chuẩn hoặc triển khai phần mềm, thường có những tác vụ lặp đi lặp lại mà bạn sẽ phải thực hiện mỗi khi có một hành động Git nào đó diễn ra.

Git Hooks hoạt động dựa trên các sự kiện (event-based). Khi bạn chạy một số lệnh Git nhất định, phần mềm sẽ kiểm tra thư mục hooks bên trong repository Git để xem có script liên quan nào cần chạy hay không.

Một số script chạy trước khi hành động diễn ra (pre-hooks), có thể được sử dụng để đảm bảo mã tuân thủ tiêu chuẩn, kiểm tra tính hợp lệ (sanity checking), hoặc thiết lập môi trường. Các script khác chạy sau một sự kiện (post-hooks) để triển khai mã, thiết lập lại quyền chính xác (điều mà Git không theo dõi tốt), v.v.

Sử dụng những khả năng này, bạn có thể thực thi các chính sách, đảm bảo tính nhất quán, kiểm soát môi trường của mình và thậm chí xử lý các tác vụ triển khai (deployment).

Phân loại Hooks trong Git

Cuốn sách “Pro Git” của Scott Chacon đã cố gắng phân chia các loại hooks khác nhau thành các danh mục. Ông ấy phân loại chúng như sau:

• Client-Side Hooks (Hooks phía máy khách): Là các hooks được gọi và thực thi trên máy tính của người thực hiện. Loại này tiếp tục được chia thành một vài danh mục riêng biệt:
  • Committing-Workflow hooks: Các hooks này được sử dụng để xác định các hành động nên được thực hiện khi một commit đang được tạo. Chúng được dùng để chạy kiểm tra tính hợp lệ, điền trước thông báo commit và xác minh chi tiết thông báo. Bạn cũng có thể sử dụng chúng để cung cấp thông báo khi commit.
  • Email Workflow hooks: Danh mục hooks này bao gồm các hành động được thực hiện khi làm việc với các bản vá (patches) được gửi qua email. Các dự án như nhân Linux gửi và xem xét các bản vá bằng phương pháp email. Chúng có nét tương đồng với commit hooks, nhưng có thể được sử dụng bởi các maintainer chịu trách nhiệm áp dụng mã được gửi.
  • Other (Khác): Các hooks phía máy khách khác bao gồm các hooks thực thi khi merge (hợp nhất), checkout (chuyển đổi nhánh), rebase (tái cơ sở), rewrite (viết lại lịch sử), và cleaning repos (dọn dẹp repository).
• Server-Side Hooks (Hooks phía máy chủ): Các hooks này được thực thi trên các máy chủ được sử dụng để nhận các push.Chacon lại chia chúng thành các danh mục:
  • Pre-receive và post-receive: Các hooks này được thực thi trên máy chủ nhận một push để làm những việc như kiểm tra sự tuân thủ dự án và triển khai sau khi push.
  • Update: Hook này giống như pre-receive, nhưng hoạt động trên cơ sở từng nhánh để thực thi mã trước khi mỗi nhánh được chấp nhận.

Những phân loại này rất hữu ích để có cái nhìn tổng quan về các sự kiện mà bạn có thể tùy chọn thiết lập một hook. Nhưng để thực sự hiểu cách các mục này hoạt động, tốt nhất là thử nghiệm và tìm ra những giải pháp bạn đang cố gắng triển khai.

Lưu ý về biến môi trường với Git Hooks

Trước khi bạn có thể bắt đầu viết script cho hook của mình, bạn cần tìm hiểu một chút về các biến môi trường mà Git thiết lập khi gọi các hooks. Để script của bạn hoạt động, cuối cùng bạn sẽ cần hủy thiết lập (unset) một biến môi trường mà Git thiết lập khi gọi hook post-commit.

Đây là một điểm rất quan trọng cần ghi nhớ nếu bạn muốn viết các Git hooks hoạt động một cách đáng tin cậy. Git thiết lập các biến môi trường khác nhau tùy thuộc vào hook nào đang được gọi. Điều này có nghĩa là môi trường mà Git đang lấy thông tin từ sẽ khác nhau tùy thuộc vào hook.

Vấn đề đầu tiên với điều này là nó có thể làm cho môi trường scripting của bạn rất khó đoán nếu bạn không biết các biến nào đang được thiết lập tự động. Vấn đề thứ hai là các biến được thiết lập gần như hoàn toàn không có trong tài liệu của Git.

May mắn thay, Mark Longair đã phát triển một phương pháp để kiểm tra từng biến mà Git thiết lập khi chạy các hooks này. Nó bao gồm việc đặt nội dung sau vào các script Git hook khác nhau:

#!/bin/bash
echo Running $BASH_SOURCE
set | egrep GIT
echo PWD is $PWD

Thông tin trên trang của ông ấy là từ năm 2011, làm việc với Git phiên bản 1.7.1, vì vậy đã có một vài thay đổi. Hướng dẫn này sử dụng Ubuntu 20.04 với Git 2.25.1.

Dưới đây là kết quả của các thử nghiệm trên phiên bản Git này (bao gồm thư mục làm việc như Git thấy khi chạy mỗi hook). Thư mục làm việc cục bộ cho thử nghiệm là /home/sammy/test_hooks và remote bare repository (nếu cần) là /home/sammy/origin/test_hooks.git:

• Hooks: applypatch-msg, pre-applypatch, post-applypatch
  • Biến môi trường:
    • GIT_AUTHOR_DATE='Mon, 11 Aug 2014 11:25:16 -0400'
    • GIT_AUTHOR_EMAIL=sammy@example.com
    • GIT_AUTHOR_NAME=SammyUser'
    • GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
    • GIT_REFLOG_ACTION=am
  • Thư mục làm việc: /home/sammy/test_hooks
• Hooks: pre-commit, prepare-commit-msg, commit-msg, post-commit
  • Biến môi trường:
    • GIT_AUTHOR_DATE='@1407774159 -0400'
    • GIT_AUTHOR_EMAIL=sammy@example.com
    • GIT_AUTHOR_NAME=SammyUser'
    • GIT_DIR=.git
    • GIT_EDITOR=:
    • GIT_INDEX_FILE=.git/index
    • GIT_PREFIX=
  • Thư mục làm việc: /home/sammy/test_hooks
• Hooks: pre-rebase
  • Biến môi trường:
    • GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
    • GIT_REFLOG_ACTION=rebase
  • Thư mục làm việc: /home/sammy/test_hooks
• Hooks: post-checkout
  • Biến môi trường:
    • GIT_DIR=.git
    • GIT_PREFIX=
  • Thư mục làm việc: /home/sammy/test_hooks
• Hooks: post-merge
  • Biến môi trường:
    • GITHEAD_4b407c...
    • GIT_DIR=.git
    • GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
    • GIT_PREFIX=
    • GIT_REFLOG_ACTION='pull other master'
  • Thư mục làm việc: /home/sammy/test_hooks
• Hooks: pre-push
  • Biến môi trường:
    • GIT_PREFIX=
  • Thư mục làm việc: /home/sammy/test_hooks
• Hooks: pre-receive, update, post-receive, post-update
  • Biến môi trường:
    • GIT_DIR=.
  • Thư mục làm việc: /home/sammy/origin/test_hooks.git
• Hooks: pre-auto-gc
  • (Không rõ vì khó kích hoạt một cách đáng tin cậy)
• Hooks: post-rewrite
  • Biến môi trường:
    • GIT_AUTHOR_DATE='@1407773551 -0400'
    • GIT_AUTHOR_EMAIL=sammy@example.com
    • GIT_AUTHOR_NAME=SammyUser'
    • GIT_DIR=.git
    • GIT_PREFIX=
  • Thư mục làm việc: /home/sammy/test_hooks

Những biến này có ý nghĩa về cách Git nhìn nhận môi trường của nó. Bạn sẽ sử dụng thông tin trên về các biến để đảm bảo script của bạn tính đến môi trường một cách chính xác.

Bây giờ bạn đã có tất cả thông tin chung này, chúng ta có thể trình bày cách triển khai chúng trong một vài trường hợp.

Thiết lập Repository ban đầu

Để bắt đầu, chúng ta sẽ tạo một repository mới, trống rỗng trong thư mục home của bạn. Bạn có thể gọi nó là proj.

mkdir ~/proj
cd ~/proj
git init

Output
Initialized empty Git repository in /home/sammy/proj/.git/

Đối với phần còn lại của hướng dẫn này, hãy thay thế sammy bằng tên người dùng của bạn khi cần.

Bây giờ, bạn đang ở trong thư mục làm việc trống của một thư mục được kiểm soát bởi Git. Trước khi làm bất cứ điều gì khác, hãy vào repository được lưu trữ trong tệp ẩn .git bên trong thư mục này:

cd .git
ls -F

Output
branches/  config  description  HEAD  hooks/  info/  objects/  refs/

Bạn sẽ thấy một số tệp và thư mục. Cái mà chúng ta quan tâm là thư mục hooks:

cd hooks
ls -l

Output
total 40
-rwxrwxr-x 1 sammy sammy  452 Aug  8 16:50 applypatch-msg.sample
-rwxrwxr-x 1 sammy sammy  896 Aug  8 16:50 commit-msg.sample
-rwxrwxr-x 1 sammy sammy  189 Aug  8 16:50 post-update.sample
-rwxrwxr-x 1 sammy sammy  398 Aug  8 16:50 pre-applypatch.sample
-rwxrwxr-x 1 sammy sammy 1642 Aug  8 16:50 pre-commit.sample
-rwxrwxr-x 1 sammy sammy 1239 Aug  8 16:50 prepare-commit-msg.sample
-rwxrwxr-x 1 sammy sammy 1352 Aug  8 16:50 pre-push.sample
-rwxrwxr-x 1 sammy sammy 4898 Aug  8 16:50 pre-rebase.sample
-rwxrwxr-x 1 sammy sammy 3611 Aug  8 16:50 update.sample

Bạn có thể thấy một vài điều ở đây. Đầu tiên, bạn có thể thấy rằng mỗi tệp này đều được đánh dấu là có thể thực thi (executable). Vì các script này chỉ được gọi theo tên, chúng phải có quyền thực thi và dòng đầu tiên của chúng phải là một tham chiếu “shebang magic number” để gọi trình thông dịch script chính xác. Thông thường nhất, đây là các ngôn ngữ scripting như bash, perl, python, v.v.

Điều thứ hai bạn có thể nhận thấy là tất cả các tệp đều kết thúc bằng .sample. Điều đó là do Git chỉ nhìn vào tên tệp khi cố gắng tìm các tệp hook để thực thi. Việc sai lệch so với tên script mà Git đang tìm kiếm về cơ bản sẽ vô hiệu hóa script. Để kích hoạt bất kỳ script nào trong thư mục này, bạn sẽ phải xóa hậu tố .sample.

Ví dụ 1: Triển khai lên Local Web Server với Post-Commit Hook

Ví dụ đầu tiên của chúng ta sẽ sử dụng hook post-commit để chỉ cho bạn cách triển khai lên một máy chủ web cục bộ bất cứ khi nào một commit được thực hiện. Đây không phải là hook bạn sẽ sử dụng cho môi trường production, nhưng nó cho phép chúng ta trình bày một số mục quan trọng, ít được ghi lại mà bạn nên biết khi sử dụng hooks.

Đầu tiên, bạn sẽ cài đặt máy chủ web Apache để minh họa:

sudo apt-get update
sudo apt-get install apache2

Để script của bạn có thể sửa đổi thư mục gốc của web tại /var/www/html (đây là document root trên Ubuntu 20.04. Hãy sửa đổi nếu cần), bạn cần có quyền ghi. Đầu tiên, hãy cấp quyền sở hữu thư mục này cho người dùng bình thường của bạn. Bạn có thể làm điều này bằng cách gõ:

sudo chown -R `whoami`:`id -gn` /var/www/html

Bây giờ, trong thư mục dự án của bạn, hãy tạo một tệp index.html:

cd ~/proj
nano index.html

Bên trong, bạn có thể thêm một chút mã HTML chỉ để minh họa ý tưởng. Nó không cần phải phức tạp:

<h1>Here is a title!</h1>

<p>Please deploy me!</p>

Thêm tệp mới để Git theo dõi:

git add .

Bây giờ, trước khi bạn commit, bạn sẽ thiết lập hook post-commit cho repository của mình. Tạo tệp này trong thư mục .git/hooks của dự án:

nano .git/hooks/post-commit

Vì Git hooks là các script tiêu chuẩn, bạn cần báo cho Git sử dụng bash bằng cách bắt đầu với một shebang:

#!/bin/bash
unset GIT_INDEX_FILE
git --work-tree=/var/www/html --git-dir=$HOME/proj/.git checkout -f

Trong dòng tiếp theo, bạn cần xem xét kỹ các biến môi trường được thiết lập mỗi khi hook post-commit được gọi. Đặc biệt, biến GIT_INDEX_FILE được đặt thành .git/index.

Đường dẫn này liên quan đến thư mục làm việc (working directory), trong trường hợp này là /var/www/html. Vì index của Git không tồn tại ở vị trí này, script sẽ thất bại nếu bạn để nguyên. Để tránh tình huống này, bạn có thể thủ công unset biến này.

Sau đó, bạn chỉ cần sử dụng Git để giải nén phiên bản mới nhất của repository sau commit vào thư mục web của bạn. Bạn sẽ muốn buộc giao dịch này (-f hoặc --force) để đảm bảo nó thành công mỗi lần.

Khi bạn hoàn tất các thay đổi này, hãy lưu và đóng tệp.

Vì đây là một tệp script thông thường, bạn cần cấp quyền thực thi cho nó:

chmod +x .git/hooks/post-commit

Bây giờ, bạn đã sẵn sàng commit các thay đổi bạn đã thực hiện trong Git repo của mình. Đảm bảo rằng bạn đã quay lại thư mục chính xác và sau đó commit các thay đổi:

cd ~/proj
git commit -m "here we go..."

Bây giờ, nếu bạn truy cập tên miền hoặc địa chỉ IP của máy chủ trong trình duyệt, bạn sẽ thấy tệp index.html mà bạn đã tạo:

http://server_domain_or_IP

 

Như bạn có thể thấy, những thay đổi gần đây nhất của bạn đã tự động được đẩy lên thư mục gốc của máy chủ web ngay sau khi commit. Bạn có thể thực hiện một số thay đổi bổ sung để thấy rằng nó hoạt động trên mỗi commit:

echo "<p>Here is a change.</p>" >> index.html
git add .
git commit -m "First change"

Khi bạn làm mới trình duyệt, bạn sẽ ngay lập tức thấy các thay đổi mới mà bạn đã áp dụng:

Như bạn thấy, loại thiết lập này có thể giúp việc kiểm thử các thay đổi cục bộ dễ dàng hơn. Tuy nhiên, bạn hầu như không bao giờ muốn publish ngay lập tức khi commit trong môi trường production. An toàn hơn nhiều là push sau khi bạn đã kiểm thử mã của mình và chắc chắn rằng nó đã sẵn sàng.

Sử dụng Git Hooks để triển khai lên Production Server riêng biệt

Trong ví dụ tiếp theo này, chúng ta sẽ trình bày một cách tốt hơn để cập nhật máy chủ production. Bạn có thể làm điều này bằng cách sử dụng mô hình “push-to-deploy” để cập nhật máy chủ web của bạn bất cứ khi nào bạn push vào một Git repository bare. Bạn có thể sử dụng cùng máy chủ mà bạn đã thiết lập làm máy phát triển của mình.

Trên máy production của bạn, bạn sẽ thiết lập một máy chủ web khác, một Git repository bare mà bạn sẽ push các thay đổi vào, và một Git hook sẽ thực thi bất cứ khi nào một push được nhận.

Hoàn thành các bước dưới đây với tư cách là người dùng bình thường có quyền sudo.

Thiết lập Post-Receive Hook trên Production Server

Trên máy chủ production, hãy bắt đầu bằng cách cài đặt máy chủ web:

sudo apt-get update
 sudo apt-get install apache2

Một lần nữa, bạn nên cấp quyền sở hữu thư mục gốc của tài liệu web cho người dùng mà bạn đang vận hành:

sudo chown -R `whoami`:`id -gn` /var/www/html

Bạn cũng cần cài đặt Git trên máy này:

sudo apt-get install git

Bây giờ, bạn có thể tạo một thư mục trong thư mục home của người dùng để chứa repository. Sau đó, bạn có thể di chuyển vào thư mục đó và khởi tạo một repository bare. Một repository bare không có thư mục làm việc và tốt hơn cho các máy chủ mà bạn sẽ không làm việc trực tiếp nhiều:

mkdir ~/proj.git
cd ~/proj.git
git init --bare

Vì đây là một repository bare, không có thư mục làm việc và tất cả các tệp thường nằm trong .git giờ đây nằm trong thư mục chính của repository.

Tiếp theo, bạn cần tạo một Git hook khác. Lần này, bạn quan tâm đến hook post-receive, hook này được chạy trên máy chủ nhận một git push. Mở tệp này trong trình soạn thảo của bạn:

nano hooks/post-receive

Một lần nữa, bạn cần bắt đầu bằng cách xác định loại script bạn đang viết. Sau đó, bạn có thể gõ lệnh checkout tương tự mà bạn đã sử dụng trong tệp post-commit của mình, được sửa đổi để sử dụng các đường dẫn trên máy này:

#!/bin/bash
while read oldrev newrev ref
do
if [[ $ref =~ .*/master$ ]];
then
echo "Master ref received.  Deploying master branch to production..."
git --work-tree=/var/www/html --git-dir=$HOME/proj.git checkout -f
else
echo "Ref $ref successfully received.  Doing nothing: only the master branch may be deployed on this server."
fi
done

Vì đây là một repository bare, --git-dir nên trỏ đến thư mục cấp cao nhất của repo đó ($HOME/proj.git).

Tuy nhiên, bạn cần thêm một số logic bổ sung vào script này. Nếu bạn vô tình push một nhánh test-feature lên máy chủ này, bạn không muốn nó được triển khai. Bạn muốn đảm bảo rằng bạn chỉ triển khai nhánh master.

Đầu tiên, bạn cần đọc đầu vào chuẩn (standard input). Đối với mỗi ref đang được push, ba phần thông tin (old rev, new rev, ref) sẽ được đưa vào script, được phân tách bằng khoảng trắng, dưới dạng đầu vào chuẩn. Bạn có thể đọc điều này bằng một vòng lặp while để bao quanh lệnh git.

Vì vậy, bây giờ, bạn sẽ có ba biến được thiết lập dựa trên những gì đang được push. Đối với một push nhánh master, đối tượng ref sẽ chứa một cái gì đó trông giống như refs/heads/master. Bạn có thể kiểm tra xem ref mà máy chủ đang nhận có định dạng này hay không bằng cách sử dụng một cấu trúc if.

Cuối cùng, hãy thêm một số văn bản mô tả tình huống đã được phát hiện và hành động đã được thực hiện. Bạn nên thêm một khối else để thông báo cho người dùng khi một nhánh không phải là master được nhận thành công, ngay cả khi hành động đó không kích hoạt triển khai.

Khi bạn hoàn tất, hãy lưu và đóng tệp. Nhưng hãy nhớ, bạn phải cấp quyền thực thi cho script để hook hoạt động:

chmod +x hooks/post-receive

Bây giờ, bạn có thể thiết lập quyền truy cập vào máy chủ remote này trên máy khách của mình.

Cấu hình Remote Server trên máy khách của bạn

Trở lại máy khách (phát triển) của bạn, hãy quay lại thư mục làm việc của dự án:

cd ~/proj

Bên trong, thêm máy chủ remote dưới dạng một remote có tên production. Lệnh bạn gõ sẽ trông giống như thế này:

git remote add production sammy@remote_server_domain_or_IP:proj.git

Bây giờ push nhánh master hiện tại của bạn lên máy chủ production:

git push production master

Nếu bạn chưa cấu hình khóa SSH, bạn có thể phải nhập mật khẩu của người dùng máy chủ production của mình. Bạn sẽ thấy một cái gì đó trông giống như thế này:

Output
Counting objects: 8, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 473 bytes | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
remote: Master ref received.  Deploying master branch to production...
To sammy@107.170.14.32:proj.git
   009183f..f1b9027  master -> master

Như bạn thấy, văn bản từ hook post-receive của bạn nằm trong đầu ra của lệnh. Nếu bạn truy cập tên miền hoặc địa chỉ IP của máy chủ production trong trình duyệt web, bạn sẽ thấy phiên bản hiện tại của dự án của bạn:

Có vẻ như hook đã push mã của bạn lên production thành công ngay khi nhận được thông tin.

Bây giờ, đã đến lúc thử nghiệm một số mã mới. Trở lại máy phát triển, bạn sẽ tạo một nhánh mới để giữ các thay đổi của mình. Tạo một nhánh mới có tên test_feature và checkout nhánh mới bằng cách gõ:

git checkout -b test_feature

Bạn hiện đang làm việc trong nhánh test_feature. Hãy thử thực hiện một thay đổi mà bạn có thể muốn chuyển sang production. Bạn sẽ commit nó vào nhánh này:

echo "<h2>New Feature Here</h2>" >> index.html
git add .
git commit -m "Trying out new feature"

Tại thời điểm này, nếu bạn truy cập địa chỉ IP hoặc tên miền của máy phát triển của bạn, bạn sẽ thấy các thay đổi của bạn được hiển thị:

Điều này là do máy phát triển của bạn vẫn đang được triển khai lại sau mỗi commit. Quy trình làm việc này rất tuyệt vời để kiểm thử các thay đổi trước khi chuyển chúng sang production.

Bạn có thể push nhánh test_feature của mình lên máy chủ production remote:

git push production test_feature

Bạn sẽ thấy thông báo khác từ hook post-receive của bạn trong đầu ra:

Output
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 301 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Ref refs/heads/test_feature successfully received.  Doing nothing: only the master branch may be deployed on this server.
To sammy@107.170.14.32:proj.git
   83e9dc4..5617b50  test_feature -> test_feature

Nếu bạn kiểm tra máy chủ production trong trình duyệt một lần nữa, bạn sẽ thấy không có gì thay đổi. Đây là điều bạn mong đợi, vì thay đổi bạn push không nằm trong nhánh master.

Bây giờ bạn đã kiểm thử các thay đổi của mình trên máy phát triển, bạn chắc chắn rằng bạn muốn tích hợp tính năng này vào nhánh master của mình. Bạn có thể checkout nhánh master và merge nhánh test_feature của bạn trên máy phát triển:

git checkout master
git merge test_feature

Bây giờ, bạn đã hợp nhất tính năng mới vào nhánh master. Push lên máy chủ production sẽ triển khai các thay đổi của bạn:

git push production master

Nếu bạn kiểm tra tên miền hoặc địa chỉ IP của máy chủ production, bạn sẽ thấy các thay đổi của mình:

Sử dụng quy trình làm việc này, bạn có thể có một máy phát triển sẽ ngay lập tức hiển thị bất kỳ thay đổi nào đã được commit. Máy production sẽ được cập nhật bất cứ khi nào bạn push nhánh master.

Kết luận

Nếu đã theo dõi đến đây, chắc hẳn bạn đã thấy những cách khác nhau mà Git Hooks có thể giúp tự động hóa một số tác vụ của bạn. Chúng có thể giúp bạn triển khai mã của mình, hoặc giúp bạn duy trì các tiêu chuẩn chất lượng bằng cách từ chối các thay đổi hoặc thông báo commit không tuân thủ.

Hy vọng bài viết này hữu ích và giúp bạn hiểu rõ hơn về Git Hooks.