Git release workflow: tag, changelog, hotfix và revert an toàn

Release cần nhiều hơn merge vào main#

Với team nhỏ, merge vào main rồi deploy có thể đủ. Nhưng khi sản phẩm có khách hàng thật, bạn cần biết release nào đang chạy, thay đổi nào nằm trong release đó, hotfix đi đường nào và rollback commit nào nếu lỗi. Git release workflow giúp biến lịch sử commit thành lịch sử phát hành có thể audit.

Tag đánh dấu artifact phát hành#

Tag giúp gắn một tên ổn định cho commit release. Với web app deploy liên tục, tag có thể là v2026.04.25-1 hoặc semantic version nếu sản phẩm phát hành theo version. Điều quan trọng là tag trỏ tới đúng commit đã build artifact.

git tag -a v1.4.2 -m "Release v1.4.2"
git push origin v1.4.2

Annotated tag lưu thêm metadata như message, tagger và ngày tạo. Với release chính thức, annotated tag thường rõ ràng hơn lightweight tag.

Changelog nên viết cho người đọc#

Changelog không phải dump toàn bộ commit message. Nó nên nhóm thay đổi theo ý nghĩa: Added, Changed, Fixed, Security, Deprecated, Removed. Người đọc cần biết release này ảnh hưởng gì tới người dùng, API, vận hành hoặc dữ liệu.

• Added: chức năng mới.
• Changed: thay đổi hành vi hiện có.
• Fixed: bug fix.
• Security: vá rủi ro bảo mật.
• Migration: thay đổi database hoặc thao tác vận hành cần chú ý.

Hotfix nên đi đường ngắn nhưng có kiểm soát#

Khi production lỗi, hotfix cần nhanh nhưng không nên bỏ hết kiểm soát. Nhánh hotfix nên xuất phát từ commit production hiện tại hoặc main nếu main đại diện production. Sau khi fix, chạy test liên quan, review nhanh, tag release mới và merge lại để main không lệch.

git switch -c hotfix/login-timeout v1.4.2
# fix code, test
git commit -m "fix login timeout handling"
git tag -a v1.4.3 -m "Hotfix v1.4.3"

Điểm quan trọng là tránh sửa trực tiếp trên server. Hotfix vẫn phải đi qua Git để có lịch sử và khả năng audit.

Revert thường an toàn hơn rewrite history#

Nếu một commit đã nằm trên branch shared hoặc production, git revert thường an toàn hơn xóa lịch sử. Revert tạo commit mới đảo ngược thay đổi, giữ lịch sử rõ ràng. Rewrite history có thể phù hợp branch cá nhân, nhưng nguy hiểm trên branch nhiều người dùng.

git revert abc1234
git push origin main

Với merge commit, revert cần chỉ định parent. Hãy đọc kỹ diff sau revert và chạy test vì revert logic có thể gây conflict nghiệp vụ nếu các commit sau đó phụ thuộc vào thay đổi bị đảo ngược.

Checklist release với Git#

• Main hoặc release branch phản ánh trạng thái deploy rõ ràng.
• Mỗi release có tag hoặc build number truy về commit.
• Changelog nói theo tác động, không chỉ theo commit.
• Hotfix đi qua branch, review tối thiểu và CI liên quan.
• Revert dùng cho thay đổi đã public thay vì rewrite history.
• Release note nêu rõ migration, config change và rollback note nếu có.

Nguồn tham khảo chính#

• Git Docs: git tag
• Git Docs: git revert
• Git Docs: git merge