Điều gì tạo nên một commit và commit message tốt?

Question

Accepted Answer

Commit tốt là **tập trung** (một thay đổi logic) với **thông điệp rõ ràng** giải thích cái gì đã thay đổi và tại sao. Các commit và message được tạo cẩn thận làm lịch sử dự án dễ đọc, hữu ích cho việc hiểu các thay đổi, gỡ lỗi và cộng tác.

## Commit message tốt

```text
Cấu trúc message TỐT:
  Dòng tóm tắt ngắn (~50 ký tự, thể mệnh lệnh, viết hoa đầu, không dấu chấm cuối)
  <dòng trống>
  Phần thân tùy chọn: giải thích CÁI GÌ và TẠI SAO (không phải làm thế nào — mã cho thấy cách làm),
  ngắt dòng ở ~72 ký tự. Tham chiếu issue nếu liên quan.
```

```text
✅ TỐT:
  Add user email validation to registration form

Validate email format before submission to prevent invalid
  accounts. Fixes #142.

❌ TỆ:
  "fixed stuff", "update", "asdf", "changes", "wip"
  → mơ hồ, không cung cấp thông tin — vô dụng khi rà soát lịch sử sau này
```

## Quy ước thể mệnh lệnh

```text
Viết phần tóm tắt như một MỆNH LỆNH/chỉ thị (thể mệnh lệnh):
  ✓ "Add feature", "Fix bug", "Update docs", "Remove dead code"
  ✗ "Added feature", "Fixes bug", "Updating docs"
→ Quy ước: nó đọc như "commit này sẽ [Add feature]" (khớp với message của chính Git).
```

## Commit tốt: atomic và tập trung

```text
✓ ATOMIC — mỗi commit là MỘT thay đổi logic (không phải nhiều thay đổi không liên quan gộp lại)
✓ Tập trung — "Add login" và "Fix typo" là các commit RIÊNG BIỆT, không phải một
✓ Hoạt động được — lý tưởng là mỗi commit để lại mã ở trạng thái hoạt động được
Vì sao: commit tập trung dễ REVIEW, REVERT (hoàn tác một thay đổi gọn gàng) hơn,
  dễ hiểu, và dễ bisect (tìm commit nào đã gây ra một lỗi).
```

## Conventional Commits (một chuẩn phổ biến)

```text
type(scope): description    → feat: add login | fix: handle null | docs: update README
  các type: feat, fix, docs, refactor, test, chore, v.v.
→ Cho phép changelog/versioning tự động; được áp dụng rộng rãi trong nhiều dự án.
```

## Tại sao điều này quan trọng

Hiểu điều gì tạo nên commit và commit message tốt là có giá trị để **tạo lịch sử dự án dễ đọc, hữu ích**, nên đó là kiến thức thực hành quan trọng ảnh hưởng đáng kể đến cộng tác và khả năng bảo trì. **Commit message tốt** quan trọng vì lịch sử commit là một dạng tài liệu then chốt — các message rõ ràng (một tóm tắt súc tích giải thích *cái gì* đã thay đổi, với phần thân giải thích *tại sao* khi cần) giúp ta hiểu được mã đã tiến hóa thế nào và tại sao, điều vô giá khi rà soát lịch sử, gỡ lỗi (hiểu vì sao một thay đổi được thực hiện) hoặc onboarding.

Message mơ hồ ("fixed stuff", "update", "wip") khiến lịch sử trở nên vô dụng, làm cho việc hiểu các thay đổi sau này trở nên bất khả thi — một cái giá thực sự. **Quy ước thể mệnh lệnh** ("Add feature" chứ không phải "Added feature") là một chuẩn được tuân theo rộng rãi đáng để biết. **Commit tốt là atomic và tập trung** (mỗi commit một thay đổi logic, không phải nhiều thay đổi không liên quan gộp lại) cũng quan trọng không kém: commit tập trung dễ **review** hơn nhiều (người review hiểu một thay đổi), **revert** (hoàn tác một thay đổi gọn gàng mà không ảnh hưởng đến những cái khác), dễ hiểu, và **bisect** (tìm commit nào đã gây ra một lỗi) — nên cấu trúc commit ảnh hưởng trực tiếp đến mức độ hữu dụng của lịch sử cho việc gỡ lỗi và cộng tác.

Biết về **Conventional Commits** (chuẩn `type(scope): description` cho phép changelog và versioning tự động) là có giá trị vì nó được áp dụng rộng rãi.

Vì lịch sử commit là tài liệu quan trọng và các commit/message tốt làm nó dễ đọc và hữu ích (cho việc hiểu, review, gỡ lỗi và cộng tác) trong khi những cái tệ làm nó vô dụng, và vì tạo các commit tập trung với message rõ ràng là một dấu hiệu của thực hành Git chuyên nghiệp, hiểu điều gì tạo nên commit và commit message tốt là kiến thức có giá trị, liên quan thực tế cho cộng tác hiệu quả và lịch sử dễ bảo trì — một kỹ năng phân biệt các lập trình viên thận trọng và cải thiện đáng kể tính hữu dụng dài hạn của dự án cùng quy trình làm việc của nhóm.