การใช้ Git Commit Prefix เป็นแนวทางปฏิบัติที่ช่วยให้การทำงานร่วมกันในทีมเป็นระบบมากขึ้น ทำให้ประวัติการแก้ไข (Git History) อ่านง่าย และช่วยให้ระบบ Automate ต่าง ๆ เช่น การสร้าง Changelog อัตโนมัติทำงานได้อย่างแม่นยำ
บทความนี้จะสรุปมาตรฐานที่นิยมใช้ที่สุดคือ Conventional Commits ครับ
ทำไมต้องใช้ Git Prefix ?
- Readability: เข้าใจได้ทันทีว่าการเปลี่ยนแปลงนั้นเกี่ยวกับอะไร
- Efficiency: ค้นหาประวัติการแก้ไขได้รวดเร็วด้วยคำสั่ง
git log --grep - Automation: สามารถใช้เครื่องมือช่วยรวบรวม Version และ Release Notes ได้อัตโนมัติ
รูปแบบมาตรฐาน
รูปแบบที่นิยมที่สุดประกอบด้วย 3 ส่วนหลัก
type: description
- Type: ประเภทของการเปลี่ยนแปลง
- Scope: ส่วนของโปรเจกต์ที่ได้รับผลกระทบ เช่น
,, - Description: คำอธิบายสั้น ๆ ว่าทำอะไร (บังคับ)
ประเภทของ Prefix ที่พบบ่อย
| Prefix | การใช้งาน |
| feat | การเพิ่ม Feature ใหม่ให้กับระบบ |
| fix | การแก้ไข Bug ต่าง ๆ |
| docs | การแก้ไข Documentation |
| style | การปรับแก้รูปแบบโค้ด โดยไม่กระทบ Logic |
| refactor | การแก้ไขโค้ดเพื่อให้อ่านง่ายหรือประสิทธิภาพดีขึ้น โดยไม่มีการแก้บั๊กหรือเพิ่มฟีเจอร์ |
| perf | การปรับปรุงประสิทธิภาพ ของโค้ด |
| test | การเพิ่มหรือแก้ไข Test Cases |
| build | การเปลี่ยนแปลงที่กระทบระบบ Build หรือ External Dependencies |
| ci | การแก้ไขไฟล์ตั้งค่า CI Configuration |
| chore | งานจิปาถะอื่น ๆ เช่น การอัปเดตไฟล์ .gitignore |
| revert | การยกเลิก Commit ก่อนหน้า |
| security | Security |
ตัวอย่างการใช้งานจริง
- เพิ่มฟีเจอร์ใหม่:
feat: add google oauth2 login - แก้ไขบั๊ก:
fix: resolve memory leak in user controller - อัปเดตเอกสาร:
docs: update installation steps in README - ปรับปรุงประสิทธิภาพ:
perf: optimize query for dashboard statistics - งานทั่วไป:
chore: update dependencies
ข้อแนะนำเพิ่มเติม
- ใช้คำกริยาที่เป็นปัจจุบัน : เช่นใช้
addแทนaddedหรือaddsให้มองว่ามันคือคำสั่งว่า “ถ้า apply commit นี้ มันจะทำอะไร” - เริ่มด้วยอักษรตัวเล็ก: โดยทั่วไปนิยมใช้ตัวเล็กทั้งหมดสำหรับ Prefix
- กระชับแต่ได้ใจความ: ส่วน Description ไม่ควรยาวเกิน 50-72 ตัวอักษร
- แยกการแก้ไข: หากมีการแก้ไขหลายอย่างในคราวเดียว ควรแยกเป็นหลาย Commit เพื่อให้ใส่ Prefix ได้ถูกต้องแม่นยำ
อ่านเพิ่มเติม