Back to Blog
Git••10 min•25 views•

Quy tắc đặt tên Commit, Branch, Pull Request, Tag

Author

Minh Khoa

Author

📘 1. QUY TẮC ĐẶT TÊN COMM

Giraffe.png# IT (Commit Message Rules)

1.1 Format chuẩn

<type>: <short summary>

<body> (optional)

<footer> (optional)

1.2 Các loại commit (type) chuẩn

TypeÝ nghĩafeatThêm tính năng mớifixSửa bugdocsCập nhật tài liệustyleThay đổi không ảnh hưởng logic (format, spacing)refactorTái cấu trúc code, không thêm tính năngperfTối ưu hiệu năngtestThêm/sửa testchoreCông việc lặt vặt (config, build tool, CI/CD)

1.3 Ví dụ commit đúng chuẩn

feat: add auto-scaling logic for worker pool
fix: resolve Redis race condition during job enqueue
refactor: clean up workflow batching module
docs: update HA architecture diagrams

1.4 Quy tắc chung

  • Không viết tiếng Việt có dấu để tránh issue với tooling.
  • Summary < 72 ký tự.
  • Không dùng: “update”, “change”, “misc”, “fix bug” (quá chung chung).
  • Summary phải mô tả Hành động + Mục đích.

📘 2. QUY TẮC ĐẶT TÊN BRANCH

Cấu trúc chuẩn:

<type>/<short-description>

2.1 Các type branch thường dùng

Branch TypeDùng khifeature/Làm tính năng mớibugfix/Sửa bug của user hoặc QAhotfix/Sửa lỗi nghiêm trọng trên productionrelease/Chuẩn bị bản releaseexperiment/Thử nghiệm, prototypechore/Việc ngoài code logic (CI/CD, config)

2.2 Ví dụ

feature/ha-worker-scaling
bugfix/redis-timeout
hotfix/db-connection-leak
release/v1.3.0
experiment/batching-approach-2

📘 3. QUY TẮC ĐẶT TÊN PULL REQUEST (PR)

3.1 Format

[type] Short summary

3.2 Ví dụ

[feat] Implement worker auto-scaling with CPU threshold
[fix] Resolve webhook delay caused by Redis bottleneck
[refactor] Simplify batch-processing pipeline
[docs] Add Phase 1–3 architecture documentation

3.3 Nội dung PR bắt buộc

  • What: PR này làm gì?
  • Why: Lý do cần thay đổi?
  • How: Cách thực hiện?
  • Impact: Ảnh hưởng hệ thống?
  • Checklist:
    • [ ] Đã test local
    • [ ] Không phá backward compatibility
    • [ ] Không commit file thừa (node_modules, build, .env…)

📘 4. QUY TẮC TAG RELEASE (Git Tag Versioning)

Chuẩn dùng Semantic Versioning:

MAJOR.MINOR.PATCH

Ý nghĩa:

  • MAJOR — Thay đổi lớn, breaking changes
  • MINOR — Thêm tính năng, backward-compatible
  • PATCH — Sửa bug nhỏ, tối ưu, không thay đổi logic lớn

Ví dụ

v1.0.0   -> bản stable đầu tiên
v1.1.0   -> thêm tính năng batching
v1.1.1   -> sửa bug nhỏ
v2.0.0   -> thay đổi kiến trúc Redis + Worker

📘 5. QUY TẮC REVIEW & MERGE

5.1 Reviewer phải kiểm tra

  • Code có dễ đọc không?
  • Có test không?
  • PR có ảnh hưởng hiệu năng?
  • Có breaking changes?
  • Logs có quá noisy?

5.2 Merge Rules

  • Không merge nếu chưa có review của ít nhất 1 người khác
  • Không merge code fail CI
  • Không commit file build, file log, file môi trường (.env)

📘 6. QUY TẮC CHUNG CHO TEAM

  • Commit nhỏ, nhiều commit tốt hơn commit khổng lồ
  • PR phải “atomic” – chỉ làm 1 mục đích
  • Không để PR > 400 dòng (review khó, dễ lỗi)
  • Branch naming phải nhất quán
  • Không force push lên main/release