# GitLab Workflow

File này tóm tắt quy định GitLab nội bộ để dùng khi làm task trong công ty.

## Nguyên tắc chung

- Sử dụng GitLab công ty cho các dự án nội bộ.
- Nếu project có quy định riêng, ưu tiên quy định của project đó.
- Tên biến, tên hàm, tên nhánh và commit message bắt buộc dùng tiếng Anh.
- Không commit thông tin nhạy cảm như mật khẩu, token, file `.env`.

## Clone và tạo nhánh

```bash
git clone "<repo-url>"
cd "<project-folder>"
git checkout develop
git pull origin develop
git checkout -b "feat/portfolio-ui"
```

Quy ước tên nhánh:

- Tính năng mới: `feat/<feature-name>`
- Sửa lỗi: `fix/<bug-name>`

Ví dụ:

```bash
git checkout -b "feat/profile-assistant"
git checkout -b "fix/mobile-layout"
```

## Commit

Dùng Conventional Commits:

```text
<type>(<scope>): <subject>
```

Các `type` thường dùng:

- `feat`: thêm tính năng mới
- `fix`: sửa lỗi
- `docs`: thay đổi tài liệu
- `style`: format code, spacing, dấu chấm phẩy, không đổi logic
- `refactor`: tái cấu trúc code, không thêm feature hoặc fix bug
- `test`: thêm hoặc sửa test
- `chore`: cấu hình, script, tooling

Quy tắc subject:

- Viết tiếng Anh.
- Viết ở thì hiện tại, dạng mệnh lệnh.
- Ngắn gọn, rõ ý, không quá 50 ký tự nếu có thể.
- Không viết hoa chữ đầu nếu không cần.
- Không thêm dấu chấm ở cuối.

Ví dụ:

```bash
git add .
git commit -m "feat(ui): add portfolio hero section"
git commit -m "fix(layout): correct mobile project grid"
git commit -m "docs: add GitLab workflow guide"
```

## Push và tạo Merge Request

Sau khi hoàn thành task:

```bash
git push origin "feat/portfolio-ui"
```

Sau đó vào GitLab:

1. Tạo Merge Request từ branch đang làm.
2. Target branch là `develop`.
3. Gửi MR cho maintainer review.
4. Chỉ merge khi maintainer đã approve.

## Sau khi MR được merge

Luôn quay lại `develop`, pull code mới, rồi tạo branch mới cho task tiếp theo:

```bash
git checkout develop
git pull origin develop
git checkout -b "feat/next-task"
```

Không tiếp tục làm task mới trên branch cũ đã merge.
