Holy_Dev - Invidious

Holy_Dev

Three years of self-learning....
Tôi là 1 hạt cát trong lịch sử to lớn đang trên hành trình tự học lập trình để làm nên một điều gì đó đặc biệt. Đây là con đường mà tôi chọn, tự học hỏi, tự khẳng định bản thân mình. Thế giới luôn phát triển và tôi cũng luôn tiến lên. Gửi tôi của 10 năm sau, lúc này tôi chỉ có 129 subs và tôi vẫn đang cố gắng nâng cao skill để kiếm tiền sau này đi mông cổ cưỡi ngựa ( làm tròn giấc mộng vó ngựa thảo nguyên hồi nhỏ xem trên tv), nhưng tôi tin vào sự cố gắng của mình. Cố lên nhé tôi ơi. Ninja never quit!

View channel on YouTube

Switch Invidious Instance

Videos

Shorts

Courses

Playlists

Posts

Holy_Dev

Commit Message: Viết sao cho đúng để code dễ sống hơn
Commit message là thứ ai cũng phải viết, nhưng không phải ai cũng viết đúng. Một câu mô tả cẩu thả có thể khiến đồng đội mất thời gian, khiến bạn quay lại sửa lỗi khó hơn, hoặc làm git history trở thành một đống hỗn độn. Ngược lại, một commit message rõ ràng sẽ giúp bạn hiểu chuyện gì đã xảy ra chỉ trong vài giây.
Bộ quy tắc Conventional Commits giúp chuẩn hóa cách viết commit để mọi người trong dự án đều nói chung một ngôn ngữ. Hình minh họa bạn gửi ở trên cho thấy cấu trúc và cách áp dụng rất trực quan. Dưới đây là bản giải thích chi tiết và mượt mà hơn để bạn dùng trong bài nói hoặc bài viết.
1. Cấu trúc vàng của một commit
Một commit chuẩn sẽ có dạng:
<type>(<scope>): <description>
Trong đó:
<type>
Loại thay đổi bạn đang thực hiện. Ví dụ:
- feat: thêm tính năng
- fix: sửa lỗi
- refactor: thay đổi code không ảnh hưởng tính năng
- docs: cập nhật tài liệu
- chore: thay đổi không ảnh hưởng đến sản phẩm như update package
<scope>
Phần này không bắt buộc. Dùng khi bạn muốn nói rõ phần nào của codebase bị tác động, ví dụ auth, ui, api.
<description>
Một câu ngắn gọn mô tả bạn đã làm gì. Viết chữ thường và không chấm câu ở cuối.
Ví dụ:
feat(auth): add OAuth2 login with Google
---> Đọc một phát là hiểu ngay.
2. Một commit chỉ nên chứa một thay đổi logic
Đừng gộp sửa CSS, cập nhật API và viết thêm test vào cùng một commit. Điều này phá vỡ lịch sử thay đổi và khiến việc revert hay debug trở nên khó chịu. Mỗi commit nên trả lời đúng một câu hỏi: Bạn đã thay đổi điều gì cụ thể.
3. Khi thay đổi phức tạp, hãy thêm phần body
Phần mô tả dài (body) giúp giải thích lý do phía sau thay đổi
chứ không chỉ mô tả hành động.
Ví dụ khi bạn refactor một module vì chuẩn bị hỗ trợ tính năng mới, hãy ghi rõ tại sao.
4. Thay đổi phá vỡ tương thích cần được cảnh báo
Nếu bạn thực hiện thay đổi khiến API cũ không còn dùng được, hãy ghi ở cuối commit:
BREAKING CHANGE: <giải thích>
Câu này giúp những người khác biết rằng họ phải cập nhật code tương ứng.
5. Lợi ích thực sự của việc viết commit đúng cách
- Git history rõ ràng như bảng kiểm
- Dễ tìm lỗi
- Dễ review code
- Tự động tạo changelog nếu dùng công cụ hỗ trợ
- Giảm mâu thuẫn trong team vì mọi người tuân theo cùng một chuẩn