แน่นอนจ้ะ! ด้านล่างคือบทความหัวข้อ “Git Commit Guidelines สำหรับโปรเจกต์ Monorepo” เขียนให้พร้อมนำไปใช้ในเอกสารทีมได้ทันที:

---

Git Commit Guidelines สำหรับโปรเจกต์ Monorepo

เพื่อให้ทีมสามารถทำงานร่วมกันได้อย่างราบรื่น และเข้าใจว่าแต่ละ commit มีผลกับส่วนไหนของระบบ เราจึงใช้มาตรฐานการเขียน commit message แบบ Conventional Commits ที่ปรับให้เหมาะกับโครงสร้าง Monorepo

---

โครงสร้างข้อความ Commit

<type>(<workspace>/<project>): <ข้อความสั้น ๆ>

ตัวอย่างที่ถูกต้อง:

• feat(apps/gohig): เพิ่มหน้าลงเวลาเข้า-ออกงาน
• fix(packages/ui): แก้ปุ่ม Save ซ้ำสองครั้ง
• refactor(scripts/rename-files): เปลี่ยน logic ให้เป็น async
• chore: เปลี่ยนเวอร์ชัน Turbo

workspace คือ apps / packages / scripts / root project คือชื่อโฟลเดอร์ เช่น gohig, ui, rename-files

---

ประเภทของ Commit (type)

type	ใช้เมื่อ...
feat	เพิ่มฟีเจอร์ใหม่
fix	แก้บั๊ก
docs	แก้ไขเอกสารหรือเพิ่มเอกสารใหม่
style	แก้ฟอร์แมต, indent, white space
refactor	ปรับโครงสร้างโค้ดโดยไม่เปลี่ยนพฤติกรรม
perf	ปรับปรุงประสิทธิภาพ
test	เพิ่มหรือแก้ไขเทส
build	เปลี่ยนการตั้งค่าการ build หรือ dependency
ci	แก้การตั้งค่า pipeline เช่น GitHub Actions
chore	งานทั่วไปที่ไม่เข้ากลุ่มข้างต้น เช่น bump version
revert	ย้อนกลับ commit ก่อนหน้า

---

ข้อแนะนำเพิ่มเติม

• ความยาวข้อความ (หลัง :) ไม่ควรเกิน 72 ตัวอักษร

• อย่าใช้ข้อความคลุมเครือ เช่น update, fix bug โดยไม่ระบุว่าแก้อะไร

• ถ้ามี breaking change ให้ใส่ ! เช่น:

  refactor(packages/lib-posts)!: เปลี่ยน signature ฟังก์ชัน parse()
  

---

วิธีแก้ข้อความ Commit ที่เพิ่ง commit ไป

กรณียังไม่ push:

git commit --amend

หรือ:

git commit --amend -m "feat(apps/gohig): ปรับ UI หน้าแดชบอร์ด"

ถ้า push ไปแล้ว:

• ใช้แบบนี้ (อันตรายถ้ามีคนอื่นใช้ branch เดียวกัน):

git commit --amend -m "ข้อความใหม่"
git push --force

• หรือแบบปลอดภัยกว่า (ใช้ commit ใหม่แก้ commit ก่อนหน้า):

git commit -m "fix(commit): แก้ข้อความ commit ก่อนหน้าให้ตรง format"

---

การใช้ git cz เพื่อช่วยเขียน Commit

ติดตั้งไว้แล้วในโปรเจกต์นี้:

git cz

จะมี UI ถาม type, scope, และข้อความ commit อย่างเป็นระบบ หากจะแก้ commit ล่าสุดด้วย UI:

git cz --amend

Tip: สามารถตั้ง alias ให้สั้นลงได้ เช่น git config --global alias.cz '!npx cz'

---

ตัวอย่างที่ผิด (ควรหลีกเลี่ยง)

• update: เพิ่มปุ่ม
• แก้บั๊กในหน้าแรก
• fix UI
• Merge branch main (ถ้าเปิด squash merge จะไม่เจอ)

---

สรุป

การใช้ commit message ที่ดี ไม่ได้มีไว้เพื่อตรวจสอบเท่านั้น แต่ช่วยให้ทีมทำงานร่วมกันได้อย่างมีระบบ สื่อสารเข้าใจตรงกัน และใช้งานร่วมกับเครื่องมืออัตโนมัติ (CI/CD, release note generator) ได้เต็มที่

อย่าลืมว่า commit ที่ดี คือจุดเริ่มต้นของซอฟต์แวร์ที่ maintain ได้ 🎯

---

ถ้าต้องการรวม guideline นี้กับการตั้งค่า commitlint, cz, และ husky ทั้งระบบก็สามารถทำต่อได้ทันทีจ้ะ ✅