Cấu hình .git-blame-ignore-revs: Đừng để Prettier “cướp công” của đồng nghiệp – ITFROMZERO

Table of Contents

Khi Git Blame trở thành “kẻ nói dối”

2 giờ sáng, server production gặp lỗi logic ở module thanh toán. Tôi dán mắt vào màn hình, cố tìm xem ai là người cuối cùng sửa dòng logic tính chiết khấu. Một lệnh quen thuộc được gõ: git blame src/services/payment.js.

Kết quả hiện ra thật sự gây ức chế. Toàn bộ 200 dòng code trong file đều hiển thị tên của… chính tôi. Nội dung commit chỉ vỏn vẹn: “chore: run prettier for the whole project”.

Tuần trước tôi có chạy Prettier để dọn dẹp lại project. Vô tình, hành động này đã “ghi đè” tên tôi lên mọi dòng code. Nó che lấp tác giả thực sự của những logic quan trọng từ 2 năm trước. Tôi mất thêm 30 phút lục lại git log -p chỉ để tìm đúng cái commit gốc. Nếu dự án của bạn có hàng nghìn file, việc này đúng là một thảm họa về năng suất.

May mắn thay, Git có một tính năng cực hay để xử lý đống nhiễu này: --ignore-rev.

3 cách dọn dẹp lịch sử Git Blame

Khi các công cụ như Prettier, Black (Python) hoặc linter tự động thay đổi format, lịch sử code sẽ bị xáo trộn. Dưới đây là những cách tôi đã thử để lấy lại sự trong sạch cho git blame.

1. Truy vết thủ công bằng ký hiệu ^

Cách đơn giản nhất là yêu cầu Git blame tại thời điểm ngay trước khi commit format diễn ra:

bash
git blame <commit-hash>^ -- <file-path>

Ưu điểm: Ăn ngay, không cần cài đặt.
Nhược điểm: Chỉ hiệu quả nếu file đó mới bị format một lần. Nếu file đã qua 5-6 đợt dọn dẹp code, bạn sẽ phải “nhảy cóc” thủ công rất mệt mỏi.

2. Bỏ qua commit cụ thể qua tham số dòng lệnh

Bạn có thể chỉ định trực tiếp mã hash muốn Git lờ đi:

bash
git blame --ignore-rev <commit-hash> <file-path>

Ưu điểm: Tiện lợi khi cần kiểm tra nhanh một đoạn code nhất định.
Nhược điểm: Chẳng ai nhớ nổi cái mã hash dài dằng dặc đó. Quan trọng hơn, đồng nghiệp của bạn cũng không được hưởng lợi từ việc này.

3. Sử dụng file .git-blame-ignore-revs (Khuyên dùng)

Đây là cách làm chuyên nghiệp nhất. Chúng ta sẽ lập một “danh sách đen” các commit chỉ chứa thay đổi về định dạng và yêu cầu Git bỏ qua chúng vĩnh viễn.

Tại sao bạn nên dùng file cấu hình cho cả team?

Làm việc với các dự án legacy lâu năm, tôi nhận ra việc lưu danh sách ignore vào repo mang lại lợi ích rất lớn:

Dữ liệu đồng nhất: Mọi thành viên trong team đều thấy cùng một tác giả thực sự khi truy vết.
Hỗ trợ nền tảng: GitHub và GitLab đã hỗ trợ đọc file này để hiển thị blame chuẩn xác ngay trên trình duyệt.
Dễ bảo trì: Khi có đợt refactor lớn, bạn chỉ cần thêm một dòng mã hash vào file là xong.

Việc này giống như tạo một bộ lọc thông minh cho lịch sử dự án. Nó giúp bảo vệ “sự thật lịch sử” của code, tránh những hiểu lầm không đáng có khi cần quy trách nhiệm hoặc tìm người nắm giữ context.

Các bước triển khai chi tiết

Bước 1: Tìm mã hash của các commit format

Hãy lọc ra các commit dọn dẹp code bằng lệnh log. Ví dụ:

bash
git log --oneline --grep="prettier"

Giả sử bạn tìm thấy hai mã hash: a1b2c3d4 và e5f6g7h8.

Bước 2: Tạo file .git-blame-ignore-revs

Tạo file này ở thư mục gốc của project. Nội dung file sẽ như sau:

# Reformat toàn dự án bằng Prettier v2.0
a1b2c3d4e5f6g7h8i9j10k11l12m13n14o15p16q
# Sửa lỗi thụt đầu dòng (linting)
e5f6g7h8i9j10k11l12m13n14o15p16q17r18s19t

Mẹo nhỏ: Hãy dùng mã hash đầy đủ (40 ký tự) để đảm bảo tính chính xác tuyệt đối.

Bước 3: Kích hoạt cấu hình Git

Bạn cần thông báo cho Git biết sự tồn tại của file này bằng lệnh:

bash
git config blame.ignoreRevsFile .git-blame-ignore-revs

Để áp dụng cho mọi dự án trên máy cá nhân, bạn chỉ cần thêm flag --global. Tuy nhiên, mỗi dự án thường có danh sách commit khác nhau nên cấu hình local vẫn là tốt nhất.

Bước 4: Chia sẻ cho đồng nghiệp

Hãy commit file .git-blame-ignore-revs lên repo. Để mọi người không phải tự gõ lệnh config, bạn có thể thêm nó vào script post-install trong package.json hoặc dùng Husky hook. Như vậy, bất cứ ai clone dự án về cũng sẽ có bộ lọc blame chuẩn.

Kết quả thực tế

Thử chạy lại lệnh blame cho file payment.js ban đầu:

bash
git blame src/services/payment.js

Lúc này, Git sẽ tự động “nhìn xuyên qua” các commit Prettier. Tên của người đồng nghiệp viết logic từ năm 2022 sẽ xuất hiện trở lại. Trên giao diện GitHub, bạn cũng sẽ thấy dòng thông báo: “Ignoring revisions listed in .git-blame-ignore-revs”.

Lưu ý quan trọng: Khi nào KHÔNG nên ignore?

Quyền năng lớn đi kèm với trách nhiệm. Tôi chỉ đưa vào danh sách ignore những commit thuần túy là định dạng.

Nếu một commit vừa sửa format, vừa tiện tay fix một lỗi nhỏ, tuyệt đối không được ignore nó. Nếu bạn lờ commit đó đi, dấu vết của lần sửa bug sẽ biến mất. Điều này dẫn bạn tới một tác giả cũ hơn – người hoàn toàn không biết gì về thay đổi gần nhất.

Kinh nghiệm của tôi là: Luôn tách biệt commit format và commit logic. Đừng bao giờ trộn lẫn chúng. Nếu lỡ gộp chung rồi, hãy chấp nhận giữ lại commit đó trong lịch sử thay vì cố gắng ẩn nó đi bằng ignore-rev.

Tóm tắt quy trình

Lấy mã hash của các commit gây nhiễu lịch sử.
Lưu chúng vào file .git-blame-ignore-revs.
Chạy lệnh git config để kích hoạt bộ lọc.
Commit và push file để đồng bộ cho cả team.

Thủ thuật này sẽ giúp những pha debug đêm khuya của bạn bớt căng thẳng hơn. Bạn sẽ tìm thấy đúng người cần hỏi thay vì phải bực mình vì những dòng code vô tri từ các công cụ linter.