การใช้ 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 ได้ถูกต้องแม่นยำ
อ่านเพิ่มเติม