Một điều kiện trong code có vẻ dư thừa, nhưng xóa đi lại làm hỏng một tình huống ít gặp. Trước khi sửa, lịch sử Git có thể giúp tìm lại bối cảnh mà người viết trước đó đã xử lý. Git blame là điểm bắt đầu để điều tra, không phải công cụ kết luận ai gây ra lỗi.
1. Blame cho biết điều gì?
Tài liệu git-blame mô tả lệnh này là cách gắn thông tin revision và tác giả sửa cuối cho từng dòng. Kết quả không tự giải thích yêu cầu nghiệp vụ, cũng không chứng minh commit được chỉ ra là nơi lỗi bắt đầu.
Một dòng có thể được di chuyển, định dạng lại hoặc thay đổi vì một refactor lớn. Vì vậy, hãy dùng mã commit để mở rộng điều tra, thay vì chỉ nhìn tên người được hiển thị.
2. Bắt đầu từ vùng code nhỏ
Chạy tại gốc repository. Đường dẫn và khoảng dòng dưới đây là minh họa, phải thay theo dự án:
git status --short
git blame -L 40,65 HEAD -- src/InvoiceService.phpHEAD giúp chỉ rõ đang xem phiên bản commit hiện tại. Nếu working tree có thay đổi chưa commit, số dòng trong trình soạn thảo có thể khác phiên bản này. Xác định đúng đoạn cần xem trước khi đọc kết quả.
Chọn một vùng nhỏ giúp giữ câu hỏi rõ ràng: điều kiện xử lý ngày hóa đơn này xuất hiện khi nào? Đọc toàn bộ file dài rồi chọn ngẫu nhiên một tác giả thường không giúp tìm nguyên nhân.
3. Mở commit và tìm bằng chứng đi kèm
Giả sử blame trả mã abc1234, hãy thay mã minh họa bằng commit thật:
git show --stat abc1234
git show abc1234 -- src/InvoiceService.phpĐọc thông điệp, phần thay đổi và danh sách file liên quan. Sau đó tìm test hoặc tài liệu được sửa cùng lúc. Nếu commit có tham chiếu issue hay pull request mà bạn được phép truy cập, đọc thảo luận để hiểu các phương án đã được cân nhắc.
Không có test không có nghĩa điều kiện là vô ích. Ghi rõ phần nào đã có bằng chứng và phần nào vẫn chỉ là giả thuyết. Với commit merge, cần chú ý cách hiển thị diff và quan hệ giữa các parent trước khi diễn giải.
4. Giảm nhiễu do khoảng trắng
git blame -w -L 40,65 HEAD -- src/InvoiceService.phpTùy chọn -w bỏ qua thay đổi khoảng trắng khi truy nguồn dòng. Nó có thể giúp nhìn qua một đợt định dạng lại, nhưng không phải bộ lọc hiểu ngữ nghĩa chương trình. Nếu khoảng trắng có ý nghĩa với nội dung đang xét, phải đối chiếu bản không dùng -w.
Nếu hai lần chạy trỏ đến commit khác nhau, mở cả hai và giải thích sự khác biệt. Đừng mặc định commit cũ hơn luôn là câu trả lời đúng.
5. Đoạn code đã bị xóa: chuyển sang tìm lịch sử
Blame trên phiên bản hiện tại không liệt kê các dòng đã biến mất. git log hỗ trợ tìm thay đổi bằng chuỗi hoặc biểu thức:
git log -p -S 'legacyTaxMode' -- src/InvoiceService.php
git log -p -G 'legacyTaxMode' -- src/InvoiceService.php-S tìm các thay đổi làm số lần xuất hiện của chuỗi thay đổi; -G tìm dòng được thêm hoặc xóa trong patch khớp biểu thức chính quy. Hai lệnh không tương đương, nên việc một lệnh không trả kết quả chưa đủ để kết luận chuỗi chưa từng được sửa.
Phạm vi đường dẫn có thể bỏ sót lịch sử ở tên file khác. Nếu nghi ngờ đổi tên, thử xem lịch sử một file với:
git log --follow -p -- src/InvoiceService.phpKhả năng lần theo đổi tên có giới hạn, đặc biệt với lịch sử phức tạp. Một clone thiếu lịch sử cũng không thể cung cấp những commit chưa có tại local.
6. Biến kết quả điều tra thành kiểm thử
Ví dụ bạn tìm thấy điều kiện được thêm để xử lý hóa đơn điều chỉnh. Bước tiếp theo là tạo trường hợp kiểm thử mô tả tình huống đó, xác nhận hành vi hiện tại rồi đánh giá thay đổi dự kiến. Lịch sử giúp hình thành giả thuyết; kiểm thử giúp kiểm chứng trong hệ thống hôm nay.
- Đã xem đúng revision và đúng vùng code.
- Đã đọc commit, không chỉ tên tác giả.
- Đã tìm test, yêu cầu hoặc tài liệu giải thích.
- Đã phân biệt bằng chứng với suy đoán.
- Đã có cách kiểm tra rằng sửa mới không làm mất hành vi cần giữ.
Dùng blame để hỏi “vì sao đoạn này tồn tại?” sẽ hữu ích hơn “ai viết dòng này?”. Khi bối cảnh được chuyển thành test và ghi chú rõ ràng, lần bảo trì tiếp theo cũng bớt phụ thuộc vào trí nhớ của cả nhóm.
Chưa có bình luận. Hãy là người đầu tiên chia sẻ ý kiến.