Mở một file code cũ và bắt gặp một đoạn logic “lạ lùng” là trải nghiệm thường thấy của mọi lập trình viên. Bạn phân vân không biết đoạn code này giải quyết bài toán gì, hay ai là người đã đưa nó vào dự án? Theo một báo cáo từ Stripe, dev trung bình dành tới 42 giờ mỗi tuần chỉ để bảo trì và đọc hiểu code cũ. Con số này cho thấy việc nắm vững công cụ truy vết là cực kỳ quan trọng.
Trong thực tế, việc gõ code mới thường chỉ chiếm khoảng 30% thời gian. 70% còn lại là quá trình đào bới và thấu hiểu những gì người tiền nhiệm (hoặc chính bạn của 6 tháng trước) đã để lại. Git Blame và Git Log -L chính là hai trợ thủ đắc lực giúp bạn tiết kiệm hàng giờ đồng hồ ngồi suy luận không căn cứ.
Vào việc luôn: 2 lệnh Git cứu cánh khi debug
Nếu bạn đang cần kết quả ngay để xử lý bug, hãy sử dụng hai lệnh sau:
1. Xem nhanh ai đã sửa dòng code cuối cùng
git blame path/to/file.pyLệnh này hiển thị toàn bộ nội dung file. Mỗi dòng sẽ đi kèm commit hash, tên tác giả và thời điểm chỉnh sửa gần nhất.
2. Đào sâu lịch sử của một đoạn code cụ thể
git log -L 10,20:path/to/file.pyThay vì đọc hàng trăm commit của file, lệnh này chỉ liệt kê những thay đổi tác động trực tiếp lên dòng 10 đến 20. Cách này giúp bạn tập trung hoàn toàn vào logic của một hàm hoặc block code nhất định.
Đọc hiểu Git Blame: Đi tìm ngữ cảnh thay vì đổ lỗi
Dù cái tên “Blame” nghe có vẻ tiêu cực, giới kỹ thuật thường dùng nó để tìm kiếm Context (Ngữ cảnh). Khi chạy lệnh, bạn sẽ thấy output tương tự như sau:
^e1f42a3 (Nguyen Van A 2023-10-12 1) import os
8d2b3c4f (Tran Thi B 2024-01-05 2) def calculate_total(price, tax):
8d2b3c4f (Tran Thi B 2024-01-05 3) return price + (price * tax)Điểm ăn tiền ở đây là Commit Hash (như 8d2b3c4f). Khi gặp đoạn code khó hiểu, hãy lấy mã này và chạy git show 8d2b3c4f. Một commit message chỉn chu sẽ giải thích rõ tại sao logic đó tồn tại, giúp bạn nắm bắt yêu cầu nghiệp vụ tại thời điểm đó nhanh chóng.
Vài mẹo nhỏ để dùng Blame hiệu quả hơn:
- Loại bỏ nhiễu khoảng trắng: Nếu ai đó chỉ format lại code (thêm space, tab), hãy dùng
git blame -w. Git sẽ bỏ qua các thay đổi hiển thị để tìm đúng người thực sự sửa logic. - Kiểm tra email: Dùng
git blame -eđể phân biệt nếu team có nhiều người trùng tên. - Thu hẹp phạm vi: Đừng tốn công soi file 2000 dòng, hãy dùng
-Lđể giới hạn nhưgit blame -L 50,60 path/to/file.
Git Log -L: Theo dõi quá trình “tiến hóa” của logic
Nhiều bạn mới chỉ quen dùng git log -p để xem thay đổi. Tuy nhiên, với các file lớn, output trả về thường rất rối mắt. Git Log -L (Line-level log) giúp bạn lọc bỏ mọi thông tin thừa thãi.
Truy vết theo khoảng dòng
Giả sử bạn nghi ngờ hàm tính thuế từ dòng 15 đến 20 đang bị lỗi. Hãy gõ:
git log -L 15,20:main.pyGit sẽ chỉ hiển thị các commit liên quan đến khu vực này. Thú vị ở chỗ, Git đủ thông minh để nhận diện đoạn code ngay cả khi nó bị đẩy xuống dòng 25 hay 30 do có code mới chèn vào phía trên.
Truy vết theo tên hàm (Regex)
Đây là tính năng cực kỳ mạnh mẽ cho các ngôn ngữ như Python, Java hay C++. Bạn không cần đếm dòng mà chỉ cần gọi tên hàm:
git log -L :calculate_total:main.pyGit tự động tìm phạm vi của hàm calculate_total và liệt kê lịch sử chỉnh sửa riêng cho nó. Lưu ý: Cú pháp này hoạt động tốt nhất với các ngôn ngữ phổ biến mà Git hỗ trợ phân tích cấu trúc.
Kỹ thuật xử lý khi code bị di chuyển (Refactor)
Trong các dự án lớn, việc di chuyển code từ file này sang file khác diễn ra liên tục. Khi đó, git blame mặc định thường chỉ hiện commit refactor thay vì commit gốc tạo ra đoạn code đó. Để giải quyết, mình thường dùng thêm hai cờ bổ trợ:
- -M: Phát hiện các dòng code bị di chuyển trong cùng một file.
- -C: Tìm kiếm code được copy từ file khác sang. Nếu dùng
-CC, Git sẽ lùng sục trong toàn bộ lịch sử repository.
Ví dụ, khi tách một hàm lớn thành các helper nhỏ, git blame -C sẽ dẫn bạn về tận nguồn gốc người đã viết logic đó từ file cũ.
Kinh nghiệm thực tế: Văn hóa sử dụng công cụ
Tại các team công nghệ chuyên nghiệp, Git Blame không phải vũ khí để chỉ trích. Mình thường áp dụng nó vào 2 tình huống chính:
- Học hỏi ngữ cảnh: Thay vì ngồi đoán, mình nhắn trực tiếp cho tác giả: “Mình thấy đoạn này bạn xử lý case đặc biệt, cho mình hỏi thêm về nghiệp vụ lúc đó nhé?”. Cách này giúp bạn nắm bắt các edge case nhanh hơn bất kỳ tài liệu nào.
- Debug hồi quy (Regression): Khi hệ thống bỗng dưng lỗi,
git log -Lgiúp khoanh vùng chính xác thời điểm logic bị sai lệch so với phiên bản ổn định trước đó.
Lời khuyên: Nếu dùng VS Code, hãy cài ngay extension GitLens. Nó tích hợp git blame ngay trên dòng bạn đang gõ. Thông tin tác giả sẽ hiện mờ ngay cuối dòng code, giúp bạn tra cứu nhanh mà không cần gõ lệnh.
Tóm lại, nếu git log cho bạn cái nhìn tổng thể, thì git blame và git log -L là những chiếc kính hiển vi soi rõ từng chi tiết. Hãy tập thói quen truy vết trước khi sửa code để trở thành một lập trình viên thấu đáo và chuyên nghiệp hơn.
