Git tag: Xác minh đúng commit trước khi phát hành

Hai người cùng nói đang dùng v1.2.0 nhưng lại chạy hai bản mã khác nhau. Tên phiên bản dễ nhớ, còn điều cần đối chiếu khi phát hành là commit thực sự phía sau tên đó. Những lệnh kiểm tra dưới đây không tạo, xóa hoặc di chuyển tag.

1. Liệt kê tag đúng cách

git tag --list 'v1.*'
git tag --list 'v1.2.0'

Thay tên minh họa bằng phiên bản của dự án. Giữ --list khi muốn tra cứu: git tag kèm tên nhưng thiếu tùy chọn liệt kê có thể mang ý nghĩa tạo tag. Danh sách này chỉ phản ánh tag đang có trong repository local.

Theo tài liệu Git tag, lightweight tag là tham chiếu trực tiếp tới object, còn annotated tag có object riêng chứa thông tin người tạo, thời điểm và thông điệp. Annotated không đồng nghĩa với đã có chữ ký số.

2. Lấy commit phía sau tag

git rev-parse --verify 'refs/tags/v1.2.0^{commit}'

Cú pháp ^{commit} yêu cầu Git tìm đến object dạng commit, kể cả khi phải đi qua annotated tag. --verify yêu cầu tham chiếu hợp lệ. Xem tài liệu rev-parse để hiểu phép kiểm tra kiểu object.

Dùng đầy đủ refs/tags giúp nêu rõ đang tra tag, không phải nhánh trùng tên. Dấu nháy bảo vệ cú pháp đặc biệt khi chạy trong shell. Nếu lệnh báo lỗi, hãy kiểm tra tên và dữ liệu local; đừng tự tạo một tag mới cùng tên để làm lệnh chạy được.

Ghi lại mã commit đầy đủ cùng kết quả kiểm thử trong hồ sơ phát hành. Tên nhánh hiện tại hoặc thông điệp commit giống nhau chưa đủ để chứng minh hai bản mã đồng nhất.

3. Đối chiếu với remote mà không fetch

git ls-remote --tags origin 'refs/tags/v1.2.0' 'refs/tags/v1.2.0^{}'

Lệnh liên hệ remote origin để đọc tham chiếu nhưng không cập nhật tag local. Theo tài liệu ls-remote, annotated tag thường có thêm dòng với hậu tố ^{} chỉ object sau khi bóc lớp tag.

Với tag phát hành trỏ tới commit, so sánh commit local ở bước trước với dòng ^{} của annotated tag. Nếu là lightweight tag trỏ trực tiếp tới commit, đối chiếu dòng tag chính. Đừng so mã tag object với mã commit rồi kết luận sai rằng phiên bản khác nhau.

Không có dòng phù hợp không tự chứng minh phiên bản chưa từng tồn tại: hãy xem lỗi kết nối, quyền truy cập và remote đang dùng. Nếu hai phía khác nhau, dừng phát hành để điều tra; không force-update tag chỉ để làm chúng khớp.

4. Tag đúng chưa chứng minh artifact đúng

Giả sử tag đã trỏ đúng commit, nhưng bước build dùng thư mục còn thay đổi chưa commit hoặc lấy dependency khác. Gói được triển khai vẫn có thể khác kỳ vọng. Vì vậy, hồ sơ phát hành nên liên kết tên tag, commit, lần chạy CI và mã nhận diện artifact.

Nếu nhóm yêu cầu tag có chữ ký, thêm bước xác minh chữ ký theo cấu hình và danh sách người ký tin cậy. Một thông điệp tag đẹp hoặc mã commit khớp không thay thế chính sách xác thực nguồn phát hành.

5. Checklist trước khi bấm phát hành

• Đúng repository, remote và tên tag.
• Local phân giải được tag thành commit.
• So sánh đúng commit, không nhầm tag object.
• Giải thích được mọi khác biệt local và remote.
• Artifact được gắn với đúng commit và kết quả CI.
• Không đổi tag đã chia sẻ chỉ để sửa sai trong im lặng.

Đây là quy trình kiểm tra tham khảo, không phải báo cáo đã kiểm chứng một bản phát hành cụ thể. Chốt danh tính mã nguồn trước khi triển khai giúp việc điều tra và quay lui sau này rõ ràng hơn.