Các nhánh của project

1. Nhánh main: nhánh chính thức của project. Không làm việc trực tiếp trên nhánh này.
2. Nhánh dev: nhánh phụ dự án dùng để test, không làm việc trực tiếp trên nhánh này. Sau khi nhánh dev được test kĩ lưỡng sẽ được merge vào main.
3. Các nhánh feature: đây là các nhánh dùng làm việc và chỉnh sửa trực tiếp. Các nhánh này sẽ được checkout ra từ dev, sau khi làm xong mở pull request để merge feature vào dev để test. Quy tắc đặt tên các nhánh feature:
   • Nhánh feature sẽ được checkout ra từ dev thông qua các Issue (các task).
   • Tên nhánh được đặt theo quy tắc: SoTask_TenTask_NguoiThucHien. Ví dụ: 1_QuyTrinhLamViec_Tuan (xem ví dụ)
4. Nhánh hotfix: nhánh checkout ra từ main để hotfix, sau đó được merge vào dev để test.

Các task và label

1. Các task là những công việc sẽ phải thực hiện. Các task sẽ có các label để theo dõi tiến độ thực hiện.
2. Có tất cả 12 label:
   • To-do: Task được tạo ra sẵn để làm
   • Open: Task sẵn sàng để giải quyết
   • In-progress: Task đang được thực hiện
   • Cross-review: Task đang được review
   • Solved: Task được merge vào dev, sẵn sàng để test
   • Testing: Task đang được test
   • Verify: Task đã được test xong
   • Done: Task đã hoàn thành và close task
   • Reopen: Task có lỗi và được open lại để tiếp tục làm
   • High: Task quan trọng cần được thực hiện gấp
   • Pending: Task bị tạm dừng để thực hiện task quan trọng hơn
   • Skip: Task bị bỏ qua, không cần làm nữa
3. Quy trình thay đổi label:
   Các task To-do sẽ được tạo sẵn, chuyển sang Open để sẵn sàng thực hiện. Người đang thực hiện task nào thì chuyển label của task sang In-progress, làm xong chuyển label sang Cross-review để review trước khi merge vào dev. Sau khi merge chuyển label thành Solved để test, người test chuyển sang Testing. Test ổn chuyển sang Verify sẵn sàng merge vào main. Sau khi merge vào main task sẽ chuyển sang Done. Nếu test không ổn, chuyển lại thành Reopen để làm tiếp.
4. Task sẽ được close khi được merge vào main.

Các pull request

1. Sau khi làm xong task thì mở pull request để merge từ các nhánh feature vào dev để review. Người làm không được tự ý merge vào dev hoặc main.
2. Trước khi mở pull request, phải pull nhánh dev về giải quyết conflict nếu có.
3. Quy tắc đặt tên pull request: [#SoTask] Task thực hiện - Người thực hiện
   • Ví dụ: [#1] Quy trình làm việc - Tuấn (xem ví dụ)
4. Trong phần description của pull request, link task vào bằng cách ghi #SoTask.
5. Pull request sẽ được close khi merge vào dev.

Các commit message

1. Khi commit code phải theo quy tắc:
   • type(scope): short description (Ví dụ)
   • feat(gacha): them chuc nang gacha
2. Có các loại type sau (có thể cập nhật thêm):
   • feat: Chức năng mới
   • fix: Fix bug
   • refactor: Thay đổi tên hàm, thay đổi hiển thị mà không thêm chức năng mới hay fix bug
   • chore: Các thay đổi nhỏ như thêm file lặt vặt
   • test: Thêm các unit test
   • docs: Thêm document hướng dẫn

Xác thực admin bằng JWT.

Code mẫu dự án

Cấu trúc thư mục:

• controller: Các API controller, nhận thông tin từ các request, truyền vào các service để xử lý và trả về các respone.
• service: Xử lý các logic nghiệp vụ, sử dụng các repository để giao tiếp với database.
• repository: Các interface giao tiếp trực tiếp với các bảng trong database.
• model: Định nghĩa và đại diện cho các bảng trong database.
• dto: Data Transfer Object, tách dữ liệu trong các bảng ở database khỏi thông tin trả về respone (ex: password, deleted_flg,...).
• exception: Định nghĩa các custom Exception để try catch.
• util: Các hàm phụ không liên quan đến xử lý dữ liệu trong database.

Các bảng trong cơ sở dữ liệu sẽ được định nghĩa trực tiếp trong model, không cần viết SQL.

Cập nhật code và build lại app

docker-compose down && docker image rm -f demo-backend && docker-compose up -d