Nhóm phát triển đã sửa lỗi, nhưng bạn cần biết commit đó có mặt trong nhánh bảo trì hoặc tag phát hành nào. Thay vì mở từng nhánh, có thể dùng bộ lọc --contains của Git. Kết quả giúp truy vết lịch sử, nhưng chưa đủ để xác nhận lỗi đã được xử lý trên hệ thống đang chạy.
1. Xác định đúng commit cần tìm
Lấy mã commit từ pull request hoặc bản ghi sửa lỗi đã được xác minh. Trong các lệnh dưới đây, abc1234 chỉ là ví dụ, phải thay bằng mã thật trong repository:
git show --no-patch --oneline abc1234
git branch --contains abc1234
Lệnh đầu giúp xác nhận đang tra đúng commit. Lệnh thứ hai liệt kê các nhánh local có commit đó trong lịch sử. Theo tài liệu Git branch, bộ lọc contains chọn những nhánh có đầu nhánh là hậu duệ của commit được chỉ định. Nhánh trỏ ngay tại commit đó cũng được tính.
2. Hiểu kết quả qua một tình huống nhỏ
Giả sử main và release/old bắt đầu từ cùng một commit. Sau đó main có commit sửa lỗi, được gắn tag v1.1.0, rồi có thêm một commit khác. Nhánh release/old vẫn ở điểm xuất phát.
Trong bài kiểm thử với cấu trúc này, truy vấn commit sửa lỗi trả main nhưng không trả release/old. Main không cần trỏ đúng vào commit sửa lỗi: chỉ cần lịch sử của nó đi qua commit đó. Dấu sao trước tên nhánh trong đầu ra mặc định chỉ đánh dấu nhánh đang được checkout.
Khi lập ghi chú bàn giao, hãy ghi cả mã commit và tên nhánh. Một câu “đã có trên main” không chỉ ra bạn đang nói về commit nào, nhất là khi có nhiều lần sửa cùng một lỗi.
3. Kiểm tra nhánh remote-tracking và tag
git branch -r --contains abc1234
git tag --contains abc1234
Lệnh đầu kiểm tra các tham chiếu remote-tracking đang lưu trên máy. Nó không tự kết nối tới server để lấy trạng thái mới. Trước khi đưa ra kết luận về remote, hãy cập nhật dữ liệu bằng quy trình fetch của dự án và bảo đảm các nhánh liên quan nằm trong phạm vi fetch.
Lệnh thứ hai tìm tag chứa commit trong lịch sử, theo tài liệu Git tag. Trong ví dụ trên, kết quả có v1.1.0. Tuy nhiên, danh sách này chỉ phản ánh tag hiện có ở local; không được mặc định máy đã tải đủ mọi tag của dự án.
4. Có commit chưa có nghĩa thay đổi vẫn còn hiệu lực
Một commit sửa lỗi có thể đã được revert bởi commit sau đó. Khi ấy truy vấn contains vẫn tìm thấy commit gốc trong lịch sử, dù thay đổi của nó đã bị đảo ngược. Vì vậy, cần đọc các thay đổi tiếp theo và chạy bài kiểm thử tái hiện lỗi.
Chiều ngược lại cũng quan trọng: nếu nhóm backport bằng cherry-pick hoặc dùng squash, thay đổi tương đương có thể nằm dưới mã commit khác. Việc không thấy commit gốc không đủ để kết luận nhánh đó chưa được sửa. Hãy đối chiếu bản ghi backport, nội dung và test.
5. Tách kiểm tra Git khỏi xác nhận triển khai
Tag có chứa commit không chứng minh artifact tương ứng đã được build, triển khai thành công hoặc đang phục vụ người dùng. Để xác nhận production, cần thêm bằng chứng về phiên bản đang chạy, artifact đã triển khai và kết quả kiểm thử phù hợp.
Checklist cuối: xác minh mã commit, kiểm tra phạm vi local/remote/tag, bảo đảm dữ liệu đủ mới và đọc đúng giới hạn của kết quả. Nếu lệnh báo lỗi hoặc clone thiếu lịch sử, xử lý điều đó trước khi kết luận từ một danh sách rỗng. --contains là bước truy vết nhanh, không phải giấy chứng nhận hoàn tất sửa lỗi.




Chưa có bình luận. Hãy là người đầu tiên chia sẻ ý kiến.