Hotfix Branch: cách tạo và áp dụng trong phát triển di động

Hotfix Branch là gì?

Hotfix Branch là một nhánh tạm thời trong Git được tạo ra để sửa nhanh các lỗi nghiêm trọng trên môi trường production đang hoạt động. Không giống như các nhánh feature, được phân nhánh từ develop và tồn tại trong vài ngày hoặc vài tuần, hotfix được tạo từ main/master và chỉ tồn tại trong thời gian cần thiết để sửa lỗi.

Mục tiêu chính của hotfix là giảm thiểu thời gian giữa việc phát hiện lỗi nghiêm trọng và sửa nó trên production. Nhóm không chờ đợi sprint hiện tại hoặc chu kỳ phát hành kết thúc mà phát hành bản vá ngay lập tức. Điều này đặc biệt quan trọng đối với ứng dụng di động, nơi lỗi nghiêm trọng có thể chặn người dùng và dẫn đến rời bỏ.

Theo Google Play Console, thời gian xem xét cập nhật trung bình trên Google Play là 2 đến 24 giờ. Đối với App Store, xem xét nhanh có thể mất 1 đến 4 giờ. Các nhánh hotfix cho phép chuẩn bị bản sửa trước khi quá trình kiểm duyệt hoàn tất và phát hành ngay sau khi được phê duyệt.

Cách Hotfix hoạt động

Quy trình hotfix bao gồm ba bước: tạo nhánh từ main, thực hiện sửa lỗi vàmerge ngược vào main và develop. Sự khác biệt chính so với sửa lỗi thông thường là hotfix luôn đượcmerge vào cả hai nhánh, để bản sửa không bị mất trong lần phát hành tiếp theo.

Nhóm không nên đưa chức năng mới hoặc tái cấu trúc vào hotfix. Chỉ sửa lỗi tập trung, tối thiểu cần thiết để giải quyết vấn đề nghiêm trọng. Bất kỳ sai lệch nào khỏi quy tắc này đều làm tăng nguy cơ hồi quy và làm chậm quá trình phát hành bản vá.

Khi nào cần Hotfix

Hotfix cần thiết trong ba kịch bản: lỗi nghiêm trọng chặn người dùng (treo máy, mất dữ liệu), lỗ hổng bảo mật cần đóng ngay lập tức hoặc logic kinh doanh quan trọng bị hỏng (thanh toán, xác thực). Nếu lỗi không nghiêm trọng, nó có thể được sửa trong chu kỳ phát hành thông thường qua develop.

Đối với ứng dụng di động, hotfix cũng có thể bao gồm thay đổi phía máy chủ nếu kiến trúc cho phép bật/tắt tính năng từ xa (feature flags). Trong trường hợp này, nhánh hotfix có thể tối thiểu hoặc không cần thiết nếu bản sửa có thể thực hiện ở phía máy chủ.

Mô hình nhánh và vị trí của Hotfix

Không phải tất cả mô hình nhánh đều hỗ trợ nhánh hotfix. Git Flow truyền thống bao gồm hotfix như một loại nhánh đầy đủ, trong khi các phương pháp hiện đại hơn (GitHub Flow, Trunk-based) xử lý sửa lỗi khẩn cấp theo cách khác.

Git Flow và Hotfix

Git Flow là mô hình duy nhất mà hotfix là loại nhánh tích hợp cùng với feature và release. Trong Git Flow, hotfix được tạo từ main và sau khi hoàn thành, đượcmerge vào cả main (với thẻ phiên bản) và develop. Điều này đảm bảo bản sửa không bị mất trong lần phát hành tiếp theo.

GitHub Flow và Trunk-based

GitHub Flow không sử dụng loại nhánh riêng cho hotfix. Thay vào đó, nhà phát triển tạo một nhánh feature thông thường từ main, thực hiện sửa lỗi và mở Pull Request. Sau khi xem xét và kiểm tra CI, nhánh đượcmerge vào main và triển khai ngay lập tức. Ưu điểm là đơn giản, nhược điểm là thiếu kênh riêng cho sửa lỗi khẩn cấp.

Phát triển Trunk-based xử lý hotfix thông qua commit trực tiếp vào main (cho các trường hợp nghiêm trọng) với xem xét bắt buộc sau đó. Cách tiếp cận này đòi hỏi kỷ luật nhóm cao và kiểm thử tự động đáng tin cậy, vì các thay đổi đi vào production ngay lập tức.

Cách tạo Hotfix Branch

Tạo hotfix bắt đầu bằng việc chuyển sang nhánh chính và tạo nhánh mới với tiền tố hotfix/. Hãy xem quy trình từng bước qua ví dụ sửa lỗi nghiêm trọng trong ứng dụng di động.

Tạo nhánh từ main

Bước đầu tiên — chuyển sang main và đảm bảo nhánh đã được cập nhật. Sau đó tạo nhánh hotfix với tên rõ ràng phản ánh bản chất của việc sửa lỗi.

# Chuyển sang main và lấy các thay đổi mới nhất
git checkout main
git pull origin main

# Tạo nhánh hotfix
git checkout -b hotfix/crash-on-login

Sau khi tạo nhánh, bạn có thể thực hiện sửa lỗi. Điều quan trọng cần nhớ: hotfix nên chứa số lượng thay đổi tối thiểu. Không tái cấu trúc mã hoặc thêm tính năng mới — chỉ sửa lỗi tập trung giải quyết vấn đề.

Commit sửa lỗi

Commit trong hotfix nên có thông điệp cung cấp thông tin mô tả rõ ràng vấn đề và giải pháp. Định dạng: loại(phạm vi): mô tả ngắn + liên kết đến tác vụ trong tracker.

# Thêm các tệp đã thay đổi
git add src/ui/login/LoginActivity.kt

# Tạo commit với mô tả
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

Thông điệp commit nên chứa mô tả vấn đề và liên kết đến tác vụ. Điều này giúp tìm kiếm trong lịch sử dễ dàng và giúp đồng nghiệp hiểu những gì đã được sửa và tại sao. Đối với dự án di động, cũng thường bao gồm phiên bản ứng dụng nơi lỗi được tìm thấy.

merge vào main và develop

Bước cuối cùng làmerge hotfix ngược vào main (với thẻ phiên bản vá mới) và develop (để bản sửa được giữ lại trong lần phát hành tiếp theo). Đầu tiên,merge vào main với thẻ, sau đómerge vào develop.

# merge vào main và tạo thẻ
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# merge vào develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Đẩy thay đổi lên máy chủ
git push origin main --tags
git push origin develop

Cờ --no-ff đảm bảo tạo commitmerge, ngay cả khi hotfix có thể được áp dụng qua fast-forward. Điều này giữ lại thông tin rằng một sửa lỗi khẩn cấp đã được thực hiện và giúp phân tích lịch sử trong tương lai dễ dàng hơn.

Sự khác biệt giữa Hotfix, Feature và Release

Hotfix khác cơ bản so với nhánh feature và release về mục đích, vòng đời và quy tắcmerge. Hiểu những khác biệt này rất quan trọng để tổ chức đúng quy trình Git trong nhóm.

Nhánh feature dành cho chức năng mới. Nó tồn tại từ vài ngày đến vài tuần, được tạo từ develop vàmerge ngược vào develop. Feature có thể chứa nhiều commit, bao gồm cả thử nghiệm, sau đó được nén qua squash hoặc rebase.

Nhánh release chuẩn bị bản phát hành để triển khai. Nó được tạo từ develop, sửa các lỗi tìm thấy trong quá trình ổn định và không nhận chức năng mới. Sau khi hoàn thành, release đượcmerge vào main (có thẻ) và develop.

Hotfix thì ngược lại, được tạo vàmerge trực tiếp với main, bỏ qua develop (mặc dù sau khi sửa cũng được đồng bộ với develop). Nó chứa số lượng thay đổi tối thiểu và tồn tại trong thời gian tối thiểu. Trong khi nhánh feature hoặc release có thể trì hoãn đến chu kỳ tiếp theo, hotfix thì không thể.

Đối với phát triển di động, sự khác biệt này đặc biệt quan trọng: App Store và Google Play cho phép phát hành phiên bản vá riêng biệt với các bản phát hành chính. Nhánh hotfix đảm bảo bản phát hành vá không bị trộn lẫn với các tính năng chưa hoàn thành.

Lỗi thường gặp khi làm việc với Hotfix

Lỗi khi làm việc với hotfix có thể làm mất đi lợi ích của việc sửa lỗi khẩn cấp. Hãy xem năm vấn đề phổ biến nhất phát sinh trong các nhóm sử dụng Git Flow.

• Tạo hotfix từ develop — nếu hotfix được tạo từ develop, các tính năng chưa hoàn thành có thể vào bản vá. Hotfix chỉ nên được tạo từ main để đảm bảo chỉ có mã ổn định trong bản sửa.
• Nhiều bản sửa trong một hotfix — mỗi bản sửa nên ở nhánh hotfix riêng. Trộn nhiều lỗi trong một nhánh làm phức tạp việc xem xét mã, tăng nguy cơ hồi quy và khó khăn khi cần khôi phục.
• Bỏ quamerge vào develop — nếu hotfix không đượcmerge vào develop, bản sửa sẽ bị mất trong lần phát hành tiếp theo. Nhóm sẽ thấy cùng lỗi xuất hiện lại và phải sửa lại lần nữa.
• Thẻ phiên bản không chính xác — hotfix nên nhận tăng bản vá (v2.3.0 → v2.3.1), không phải tăng phụ (v2.4.0) hay tăng chính (v3.0.0). Vi phạm phiên bản ngữ nghĩa làm hỏng hệ thống xây dựng và gây nhầm lẫn cho người dùng.
• Thiếu kiểm tra CI — ngay cả hotfix khẩn cấp cũng phải vượt qua kiểm thử tự động. Bỏ qua CI làm tăng nguy cơ đưa lỗi mới. Nên có pipeline riêng cho nhánh hotfix với kiểm tra nhanh.

Mỗi lỗi này đều dẫn đến chậm trễ phát hành bản vá hoặc xuất hiện vấn đề mới trên production. Các nhóm nên ghi lại quy tắc làm việc với hotfix trong CONTRIBUTING.md và tự động hóa chúng qua kiểm tra CI/CD.