Cách xây dựng trình điều khiển (driver) cho Git diff tùy chỉnh

Trong quá trình làm việc với Git, đôi khi việc so sánh sự thay đổi giữa các file (diff) bằng cách thông thường là chưa đủ, đặc biệt khi bạn cần xử lý các định dạng file phức tạp hoặc muốn hiển thị thông tin chi tiết hơn. Bài viết này sẽ hướng dẫn bạn cách xây dựng một trình điều khiển (driver) bên ngoài cho git diff, giúp tùy chỉnh hoàn toàn cách hiển thị sự khác biệt giữa các phiên bản file.

Hình ảnh minh họa về Git diff

Tại sao cần xây dựng Git diff driver?

Mặc dù Git cung cấp cơ chế textconv để chuyển đổi file nhị phân sang văn bản nhằm dễ dàng so sánh hơn, nhưng trong nhiều trường hợp, chúng ta cần lộ trình thông tin chi tiết hơn mà textconv không thể đáp ứng được. Ví dụ, khi so sánh các dữ liệu đóng gói (package data) hay các đặc tả OpenAPI, việc hiển thị một bản thay đổi (changelog) dễ đọc cho con người sẽ hữu ích hơn nhiều là so sánh từng dòng code thô.

Tuy nhiên, tài liệu về cách tạo ra một công cụ diff bên ngoài (external diff tool) khá khan hiếm, khiến cho nhiều lập trình viên gặp khó khăn khi bắt đầu.

Hiểu về 7 tham số mà Git truyền vào

Một điểm quan trọng cần lưu ý là khi bạn cấu hình Git để sử dụng một công cụ bên ngoài, nó sẽ không chỉ đơn giản truyền đường dẫn của file "trước" và "sau". Thay vào đó, Git sẽ truyền vào đúng 7 tham số cho lệnh đó. Điều này có vẻ hơi thừa thãi so với nhiều công cụ dòng lệnh thông thường, nhưng nó cung cấp dữ liệu phong phú hơn để xử lý các tình huống khác nhau.

Dưới đây là danh sách các tham số theo thứ tự mà Git truyền cho script của bạn:

1. Tên file trong kho lưu trữ (repo).
2. Đường dẫn tạm đến file "trước" (old file).
3. Mã băm SHA-1 của file "trước".
4. Chế độ (mode) bát phân của file "trước" (ví dụ: 100644).
5. Đường dẫn tạm đến file "sau" (new file).
6. Mã băm SHA-1 của file "sau".
7. Chế độ (mode) bát phân của file "sau".

Xử lý các kịch bản khác nhau

Để hiểu rõ hơn cách các tham số này hoạt động, hãy xem xét cách chúng thay đổi tùy theo hành động trên file:

Khi một file hiện có được cập nhật

Git sẽ cung cấp đầy đủ thông tin cho cả file cũ và file mới, bao gồm đường dẫn tạm, mã băm và chế độ quyền hạn.

Khi một file mới được tạo (Added)

Đối với file mới, tham số thứ 2 và 3, 4 (thuộc về file "trước") sẽ không có giá trị. Cụ thể:

• Tham số 2 (đường dẫn cũ): /dev/null
• Tham số 3, 4 (hash và mode cũ): . (dấu chấm)

Khi một file bị xóa (Deleted)

Ngược lại, khi file bị xóa, các tham số thuộc về file "sau" sẽ rỗng:

• Tham số 5 (đường dẫn mới): /dev/null
• Tham số 6, 7 (hash và mode mới): .

Việc kiểm tra các giá trị đặc biệt như /dev/null trong script của bạn là rất quan trọng để xử lý đúng các trường hợp thêm hoặc xóa file.

Ví dụ thực tế: Tạo driver cho OpenAPI với oasdiff

Để minh họa, chúng ta sẽ xây dựng một script Bash đơn giản bao quanh công cụ oasdiff – một công cụ dùng để so sánh các đặc tả OpenAPI. Script này sẽ nhận các tham số từ Git và hiển thị bản thay đổi dễ đọc.

Dưới đây là đoạn mã mẫu:

#!/usr/bin/env bash
# Via https://www.jvt.me/posts/2026/04/11/oasdiff-driver/
# Một diff driver cho `git diff` để cung cấp changelog dễ đọc cho đặc tả OpenAPI

if [[ "$2" == "/dev/null" ]]; then
  echo "$1 đã được thêm mới (added)"
  exit 0
elif [[ "$5" == "/dev/null" ]]; then
  echo "$1 đã bị xóa (deleted)"
  exit 0
fi

# Ưu tiên hiển thị màu sắc để dễ đọc hơn
oasdiff changelog "$2" "$5" --color always

Trong ví dụ này:

• Chúng ta kiểm tra tham số thứ 2 ($2) để xác định xem file cũ có phải là /dev/null không, nghĩa là file đang được thêm mới.
• Tương tự, kiểm tra tham số thứ 5 ($5) để xác định file bị xóa.
• Nếu không phải trường hợp thêm hay xóa, chúng ta gọi oasdiff changelog với đường dẫn file cũ ($2) và file mới ($5).

Lưu ý: Script này chưa xử lý sự thay đổi về quyền hạn (permissions) của file. Tuy nhiên, bạn có thể sử dụng các mã băm SHA-1 (tham số 3 và 6) để lưu kết quả diff vào bộ nhớ đệm (cache) nhằm tối ưu hiệu suất nếu cần thiết.

Việc nắm vững cách Git tương tác với các công cụ bên ngoài sẽ giúp bạn mở rộng khả năng của dòng lệnh, biến quy trình code review và kiểm soát thay đổi trở nên trực quan và hiệu quả hơn rất nhiều.