แจกโพยชื่อ commit

ถ้าเพิ่งเริ่มใช้ Conventional Commits แล้วงงว่า “ต้องพิมพ์อะไรหน้าข้อความ commit ดี?” อันนี้คือแนวทางที่เราใช้จริงให้ทีมอ่านรู้เรื่องทันที และช่วยให้ประวัติ Git ดูเป็นระบบขึ้นมาก (โดยเฉพาะตอนเปิด PR/ทำรีวิว) 1) โครงสร้างพื้นฐานที่จำง่าย โดยทั่วไปจะเขียนประมาณนี้: <type>(scope): <subject> - type = ประเภทงาน เช่น feat, fix - scope (ใส่หรือไม่ก็ได้) = ส่วนของระบบที่แก้ เช่น api, ui, auth - subject = สรุปสั้นๆ ว่าทำอะไร (พยายามให้เป็นประโยคสั้น กระชับ) ตัวอย่าง: - feat(auth): add Google login - fix(cart): prevent duplicate items - docs(readme): update installation steps 2) ใช้ type ไหนเมื่อไหร่ (พร้อมตัวอย่าง) - feat: เพิ่มฟีเจอร์ใหม่ ตัวอย่าง: feat(profile): add avatar upload - fix: แก้บั๊ก/แก้พัง ตัวอย่าง: fix(payment): handle timeout correctly - refactor: ปรับโครงสร้างโค้ด ไม่เปลี่ยนพฤติกรรม ตัวอย่าง: refactor(api): simplify error handling - perf: ปรับปรุงประสิทธิภาพ ตัวอย่าง: perf(search): speed up query with index - style: แก้ format/จัดระเบียบโค้ด เช่น lint, spacing (ไม่กระทบ logic) ตัวอย่าง: style(ui): apply prettier formatting - test: เพิ่ม/แก้ test case ตัวอย่าง: test(auth): add unit tests for token refresh - docs: แก้เอกสาร เช่น README, comment ที่เป็นเอกสาร ตัวอย่าง: docs(api): document rate limit - chore: งานจิปาถะ/งานบ้าน เช่น อัปเดตแพ็กเกจเล็กน้อย ปรับสคริปต์ ตัวอย่าง: chore: bump eslint version - build: เปลี่ยนแปลงที่เกี่ยวกับ build system/dependencies ตัวอย่าง: build: update webpack config - ci: แก้ไฟล์ config ของ CI/CD ตัวอย่าง: ci: cache node_modules in GitHub Actions 3) ทริคให้ commit อ่านง่ายกว่า “update” - เริ่ม subject ด้วยกริยา (add/update/remove/fix) จะอ่านลื่นมาก - 1 commit ควรทำ “เรื่องเดียว” ถ้าแก้หลายอย่างปนกัน คนรีวิวจะตามยาก - ถ้าแก้บั๊ก ให้บอกผลลัพธ์/อาการที่แก้ เช่น “prevent crash when…” 4) ใส่ scope เมื่อไหร่ดี? ถ้าโปรเจกต์มีหลายโมดูล แนะนำใส่ scope ช่วยค้นหาใน log ได้ไว เช่น (auth), (checkout), (ui) แต่ถ้างานเล็กมากไม่ต้องฝืนใส่ก็ได้ 5) กรณี Breaking Change ถ้าเปลี่ยนแบบทำให้ของเดิมใช้ไม่ได้ (เช่น เปลี่ยนชื่อ API/เปลี่ยนพารามิเตอร์) มักใส่เครื่องหมาย ! เช่น: feat(api)!: change user endpoint response format หรืออธิบายใน body ของ commit เพิ่มว่าเป็น breaking change สรุปคือ แค่เริ่มจาก feat/fix/refactor/docs/chore/test/build/ci ให้ถูกจังหวะก่อน ก็ทำให้ทีมรู้ทันทีว่า commit นี้ “ทำอะไร” และเวลาไล่ประวัติย้อนหลังจะง่ายขึ้นมากครับ