Git Blame: Đừng Chỉ Dùng Để "Đổ Lỗi", Hãy Dùng Như Một Senior

Xin chào anh em! Khi maintain các hệ thống lớn, đặc biệt là những codebase đã tồn tại qua nhiều đời developer, chắc hẳn không ít lần bạn mở một file source code lên và thốt lên: "Trời ơi, logic gì thế này? Ai viết đoạn này vậy?".

Đó là lúc chúng ta gõ git blame. Tuy nhiên, nếu chỉ dùng git blame <tên_file> một cách đơn thuần, bạn mới chỉ chạm vào bề nổi của tảng băng chìm. Hôm nay, với chút kinh nghiệm "bầm dập" qua các dự án thực chiến, tôi sẽ chia sẻ với anh em cách làm chủ lệnh này để điều tra source code hiệu quả nhất.

1. Sống sót trong "Ma trận" Pager (Less)

Mặc định khi bạn chạy git blame, output sẽ không in thẳng ra màn hình mà được mở trong một công cụ phân trang gọi là Pager (thường là less). Nhiều anh em mới dùng sẽ thấy hơi lúng túng khi màn hình bị "kẹt" ở đây.

Đừng hoảng, hãy lưu lại bảng phím tắt sinh tồn này:

2. 5 Tuyệt chiêu "Thực chiến" với Git Blame

Đôi khi file dài cả ngàn dòng, việc lướt pager rất mất thời gian. Đây là những "ngón đòn" giúp bạn nhắm trúng đích.

Mẹo 1: Ép Git in thẳng ra Terminal (Không qua Pager) Nếu bạn muốn copy log hoặc kết hợp với các lệnh bash khác như grep, bạn có thể bypass cái Pager kia đi:

# Cách 1: Pipe qua cat
git blame <file> | cat

# Cách 2: Dùng cờ no-pager của git
git --no-pager blame <file>

Mẹo 2: "Bắt mạch" chính xác dòng code nghi vấn File General.php dài 2000 dòng và bạn chỉ quan tâm đúng cái bug ở dòng 391? Đừng blame cả file làm gì cho nặng máy, hãy dùng cờ -L (Line):

git blame -L 391,396 modules/General/Helpers/General.php

Kết quả: Git chỉ trả về lịch sử của đúng từ dòng 391 đến 396. Gọn gàng và sạch sẽ!

Mẹo 3: Tìm kiếm theo Context (Regex)

Bạn không nhớ dòng số mấy, chỉ nhớ đoạn code đó liên quan đến việc cấu hình Elasticsearch. Bạn có thể kết hợp tìm kiếm chuỗi và lấy thêm 5 dòng bên dưới nó:

git blame -L '/elasticsearch_max_result_window/',+5 modules/General/Helpers/General.php

Tips: Cái này cực kỳ hữu ích khi review code hoặc tìm kiếm nguyên nhân gây lỗi logic ở một function cụ thể mà không cần mở IDE lên đếm dòng.

Mẹo 4: Vượt qua "Cú lừa" của Format và Whitespace (Cực kỳ quan trọng)

Đây là rắc rối đau thương nhất trong các dự án lớn. Bạn chạy blame và thấy tác giả của dòng code lỗi là... anh Tech Lead. Bạn vội vàng nhắn tin thắc mắc, để rồi nhận ra anh ấy chỉ là người chạy cái tool PHP-CS-Fixer hoặc ấn Format Code làm đổi khoảng trắng (whitespace), chứ logic cũ rích kia là của người khác viết từ 2 năm trước!

Để tìm ra tác giả thật sự của đoạn logic, hãy kẹp thêm combo thần thánh -w -M -C:

• -w: Bỏ qua tất cả các thay đổi chỉ liên quan đến khoảng trắng, tabs, format.
• -M: Nhận diện code bị di chuyển (move) vị trí bên trong cùng một file.
• -C: Nhận diện code được copy từ một file khác sang.

Dùng combo này, những commit chỉ mang tính "làm đẹp code" sẽ bị lột mặt nạ, trả lại sự thật cho bạn!

Mẹo 5: Truy vết tận gốc

Git blame chỉ cho bạn biết ai viết, vào lúc nào, và ở commit nào. Nhưng để hiểu bối cảnh (Context is King), bạn cần biết lúc đó họ sửa đổi những file nào khác cùng lúc.

Sau khi lấy được mã commit_hash (nằm ở cột ngoài cùng bên trái của kết quả blame), hãy ném nó vào lệnh show:

git show <commit_hash>

Lệnh này sẽ phơi bày toàn bộ nội dung của commit đó, thông điệp commit (commit message) và các file liên quan. Nó sẽ trả lời cho câu hỏi: "Hồi đó ông ấy thêm đoạn này vào để fix cái task nào trên Jira vậy?"

Lời kết: Kỹ năng điều tra code thừa kế (legacy code) là một trong những ranh giới phân biệt giữa một Junior và một Senior. Hãy ghim lại những lệnh này, nó sẽ cứu bạn rất nhiều giờ đồng hồ gãi đầu gãi tai đấy.

Chúc anh em fix bug vui vẻ và không bao giờ blame nhầm người!