QUY ĐỊNH GIT WORKFLOW

III. Cấu trúc nhánh

Dự án sử dụng cấu trúc nhánh:

• main: nhánh production
• develop: nhánh tích hợp chung
• feature/*: phát triển tính năng
• bugfix/*: sửa lỗi
• hotfix/*: sửa lỗi khẩn cấp production

Không tạo nhánh tự do ngoài quy ước trên nếu chưa được thống nhất.

IV. Quy trình thực hiện task

4. Tạo nhánh

Nhánh phải được tạo từ develop:

• Luôn pull develop mới nhất trước khi tạo nhánh
• Không tạo nhánh từ nhánh cá nhân khác

Quy ước đặt tên nhánh:

• feature/TASKID-mo-ta-ngan
• bugfix/TASKID-mo-ta-ngan
• hotfix/TASKID-mo-ta-ngan

Yêu cầu:

• Không dùng tiếng Việt có dấu
• Không viết hoa tùy ý
• Không đặt tên chung chung như: fix, test, abc

5. Commit

Mỗi commit phải:

• Có nội dung rõ ràng
• Gắn với mã task
• Phản ánh đúng thay đổi thực tế

Cấu trúc commit message:

[TASK-ID] Loại thay đổi: Mô tả ngắn

Loại thay đổi bao gồm:

• Add
• Fix
• Update
• Refactor
• Remove
• Optimize
• Docs

Không chấp nhận commit message không có ý nghĩa.

6. Pull Request

Khi hoàn thành task:

• Push nhánh lên remote
• Tạo Pull Request vào develop
• Mô tả rõ:
• Mục đích thay đổi
• Phạm vi ảnh hưởng
• Điểm cần lưu ý

Không tự ý merge khi chưa được review.

7. Review

Mỗi Pull Request phải:

• Có ít nhất 1 người review
• Được approve trước khi merge

Reviewer có trách nhiệm:

• Đọc và hiểu logic
• Kiểm tra ảnh hưởng hệ thống
• Yêu cầu chỉnh sửa nếu cần

Approve hình thức hoặc không đọc kỹ được xem là không hoàn thành trách nhiệm review.

8. Merge và xử lý conflict

• Người tạo PR chịu trách nhiệm xử lý conflict
• Phải test lại sau khi resolve conflict
• Không force push vào nhánh chung

Sau khi merge, người thực hiện task chịu trách nhiệm theo dõi lỗi phát sinh liên quan.