คู่มือการเขียน Git Commit Message อย่างมืออาชีพ
การเขียน Git Commit Message ที่ดีเป็นทักษะที่สำคัญมากๆ สำหรับนักพัฒนาทุกคน ไม่ใช่แค่การบันทึกการเปลี่ยนแปลง แต่เป็นการสื่อสารกับเพื่อนร่วมทีมและกับตัวเราเองในอนาคตด้วย
ทำไมการเขียน Commit Message ที่ดีถึงสำคัญ?
ก่อนจะไปดูว่า “เขียนอย่างไร” เรามาเข้าใจ “ทำไม” กันก่อนครับ
เข้าใจประวัติโปรเจกต์
เมื่อย้อนกลับมาดู เราจะรู้ได้ทันทีว่าแต่ละ commit ทำอะไรไปบ้างโดยไม่ต้องไปไล่อ่านโค้ดทั้งหมด ซึ่งช่วยประหยัดเวลาในการทำความเข้าใจโค้ดเก่าอย่างมหาศาล
ช่วยในการรีวิวโค้ด
เพื่อนร่วมทีมจะเข้าใจบริบทของการเปลี่ยนแปลงได้ง่ายขึ้น ทำให้รีวิวโค้ดได้เร็วและมีประสิทธิภาพ เพราะสามารถโฟกัสที่ตรรกะของโค้ดแทนที่จะต้องเดาเจตนาของผู้เขียน
ช่วยในการหาบั๊ก
เมื่อเกิดปัญหา เราสามารถใช้ git blame หรือ git bisect เพื่อย้อนรอยหา commit ที่เป็นต้นเหตุของบั๊กได้ง่ายขึ้นมาก ทำให้การ Debug เป็นระบบและรวดเร็ว
สร้างเอกสารอัตโนมัติ
สามารถใช้เครื่องมือดึงข้อมูลจาก commit message เพื่อสร้าง Changelog (รายการการเปลี่ยนแปลง) ของเวอร์ชันใหม่ได้โดยอัตโนมัติ ช่วยลดภาระงานเอกสารและลดความผิดพลาด
โครงสร้างของ Commit Message ที่ดี (มาตรฐานสากล)
โครงสร้างที่นิยมใช้กันมากที่สุดเรียกว่า Conventional Commits ซึ่งมีรูปแบบดังนี้:
<type>(<scope>): <subject>
<body>
<footer>เรามาเจาะลึกแต่ละส่วนกันครับ
ส่วนที่ 1: Header (บรรทัดแรก)
นี่คือส่วนที่สำคัญที่สุด ประกอบด้วย type, scope (ไม่บังคับ), และ subject
<type>: ประเภทของการเปลี่ยนแปลง
บอกว่า commit นี้เป็นการเปลี่ยนแปลงประเภทไหน ประเภทที่ใช้บ่อยๆ ได้แก่:
feat: (Feature)
ใช้สำหรับการเพิ่มฟีเจอร์ใหม่เข้ามาในระบบ เช่น feat(auth): Add Google OAuth login
fix: (Bug Fix)
ใช้สำหรับการแก้ไขบั๊กที่เกิดขึ้น เช่น fix(api): Correct user data caching issue
docs: (Documentation)
ใช้สำหรับการแก้ไขหรือเพิ่มเติมเอกสารต่างๆ เช่น docs: Update installation guide
style: (Styling)
ใช้สำหรับการแก้ไขการจัดรูปแบบโค้ด (เช่น เว้นวรรค, semicolon) โดยไม่กระทบการทำงานของโปรแกรม เช่น style: Format code with Prettier
refactor: (Refactoring)
ใช้สำหรับการปรับปรุงโครงสร้างโค้ดภายใน แต่ไม่ได้เพิ่มฟีเจอร์หรือแก้บั๊ก เช่น refactor: Simplify user authentication logic
test: (Testing)
ใช้สำหรับการเพิ่มหรือแก้ไขเทสต่างๆ เช่น test: Add unit tests for login service
chore: (Chore)
ใช้สำหรับการเปลี่ยนแปลงอื่นๆ ที่ไม่เกี่ยวกับโค้ดหลัก เช่น แก้ไขไฟล์คอนฟิก, อัปเดต build script เช่น chore: Update dependencies
<scope>: ขอบเขตของการเปลี่ยนแปลง (ไม่บังคับ)
ระบุว่าการเปลี่ยนแปลงนี้กระทบส่วนไหนของโปรเจกต์ เช่น (api), (auth), (ui), (payment) ช่วยให้เห็นภาพรวมได้เร็วขึ้น
<subject>: สรุปการเปลี่ยนแปลงสั้นๆ
นี่คือกฎเหล็กของการเขียน subject:
-
ขึ้นต้นด้วยคำกริยาเชิงคำสั่ง (Imperative Mood): ให้เขียนเหมือนเรากำลัง “สั่ง” ให้ Git ทำอะไร เช่น
✅ ดี:Add user login page(เพิ่มหน้าล็อกอิน)
❌ ไม่ดี:Added user login pageหรือAdds user login page -
ความยาวไม่เกิน 50 ตัวอักษร: เพื่อให้อ่านง่ายใน
git log -
ขึ้นต้นด้วยตัวพิมพ์ใหญ่ (Capitalize):
Addไม่ใช่add -
ไม่ต้องลงท้ายด้วยจุด (.)
ข้อดี
- ทำให้ประวัติการ commit อ่านง่ายและเป็นระเบียบ
- ช่วยให้เครื่องมืออัตโนมัติสามารถวิเคราะห์และจัดการเวอร์ชันได้
- สร้างมาตรฐานที่ทีมสามารถยึดถือร่วมกันได้
ข้อจำกัด
- ในช่วงแรกอาจรู้สึกว่ามีกฎเยอะและยุ่งยาก
- ต้องใช้เวลาในการเรียนรู้และปรับตัว
- บางครั้ง scope อาจไม่ชัดเจนสำหรับโปรเจกต์เล็กๆ
ส่วนที่ 2: Body (ส่วนเนื้อหา - ไม่บังคับ)
ถ้าการเปลี่ยนแปลงซับซ้อนและ subject ไม่สามารถอธิบายได้หมด ให้เว้น 1 บรรทัดแล้วเขียนเนื้อหาอธิบายเพิ่มเติมในส่วน Body
feat(api): Implement password reset functionality via email
The previous system required administrators to manually reset passwords, which was inefficient and not scalable.
This commit introduces a new endpoint /api/auth/request-reset that
generates a secure, single-use token and sends it to the user’s
registered email address. A corresponding endpoint /api/auth/reset-password
validates the token and updates the user’s password.
- อธิบาย “ทำไม” ถึงเปลี่ยน: ปัญหาเดิมคืออะไร? ทำไมถึงต้องแก้ไขด้วยวิธีนี้?
- อธิบาย “อย่างไร” (ถ้าจำเป็น): วิธีการแก้ปัญหานี้ส่งผลกระทบต่อส่วนอื่นอย่างไรบ้าง
- ควรตัดประโยคให้ความยาวไม่เกิน 72 ตัวอักษรต่อบรรทัด: เพื่อให้อ่านง่ายใน Terminal
ส่วนที่ 3: Footer (ส่วนท้าย - ไม่บังคับ)
ใช้สำหรับใส่ข้อมูลอ้างอิงต่างๆ โดยเฉพาะการลิงก์ไปยัง Issue Tracker (เช่น Jira, GitHub Issues)
- ปิด Issue: ใช้ Keyword เช่น
Closes #123,Fixes #456เพื่อให้ GitHub หรือ GitLab ปิด Issue นั้นๆ อัตโนมัติเมื่อ commit นี้ถูก merge เข้า branch หลัก - ระบุ Breaking Change: หากการเปลี่ยนแปลงนี้ทำให้โค้ดเก่าไม่สามารถทำงานร่วมกันได้ (Backward Incompatible) ให้ระบุไว้ตรงนี้ โดยขึ้นต้นว่า
BREAKING CHANGE:แล้วตามด้วยคำอธิบาย
ตัวอย่างเปรียบเทียบ
❌ ตัวอย่างที่ไม่ดี
git commit -m "update"ปัญหา: ไม่รู้ว่าอัปเดตอะไร ที่ไหน อย่างไร
git commit -m "fixed bugs in user page"ปัญหา: ดีขึ้นมาหน่อย แต่ยังไม่เฉพาะเจาะจงว่าบั๊กอะไร
✅ ตัวอย่างที่ดี
ตัวอย่าง 1: แก้บั๊กง่ายๆ
git commit -m "fix(profile): Prevent crash when user avatar is missing"ตัวอย่าง 2: เพิ่มฟีเจอร์ที่ซับซ้อน
# ใช้ git commit (โดยไม่ใส่ -m) เพื่อเปิด Text Editor สำหรับเขียนข้อความยาวๆ
git commitแล้วพิมพ์ข้อความใน Editor:
feat(api): Implement password reset functionality via email
The previous system required administrators to manually reset passwords,
which was inefficient and not scalable.
This commit introduces a new endpoint `/api/auth/request-reset` that
generates a secure, single-use token and sends it to the user's
registered email address. A corresponding endpoint `/api/auth/reset-password`
validates the token and updates the user's password.
Closes: #88วิธีการเขียน Commit Message
แบบสั้น (สำหรับ commit ง่ายๆ):
git commit -m "feat(lang): Add Thai language support"แบบยาว (แนะนำสำหรับ commit ส่วนใหญ่):
- รันคำสั่ง
git commit(ไม่ต้องมี-m) - ระบบจะเปิดโปรแกรม Text Editor ขึ้นมา (เช่น Vim, Nano)
- พิมพ์ Header ในบรรทัดแรก
- เว้น 1 บรรทัด
- พิมพ์ Body และ Footer (ถ้ามี)
- Save และปิด Editor, commit ก็จะถูกสร้างขึ้น
สรุปเคล็ดลับ
One Change Per Commit
หนึ่ง Commit ต่อหนึ่งการเปลี่ยนแปลง (One Logical Change per Commit): อย่าจับฉ่าย รวมทุกอย่างไว้ใน commit เดียว จะทำให้ย้อนรอยยากและรีวิวโค้ดลำบาก
ใช้ภาษาอังกฤษ
เขียนเป็นภาษาอังกฤษ: เป็นมาตรฐานสากลที่คนในวงการซอฟต์แวร์เข้าใจตรงกัน (ยกเว้นทีมตกลงกันว่าจะใช้ภาษาอื่น)
อธิบาย 'ทำไม'
เขียนเพื่ออธิบาย “ทำไม” ไม่ใช่ “อะไร”: โค้ดบอกอยู่แล้วว่าคุณทำ “อะไร” แต่ commit message ควรอธิบาย “ทำไม” คุณถึงทำแบบนั้น
Conventional Commits
ใช้โครงสร้าง Conventional Commits: type(scope): subject จะทำให้ชีวิตคุณและทีมดีขึ้นมากในระยะยาว
ลองนำหลักการเหล่านี้ไปปรับใช้ดูนะครับ ช่วงแรกอาจจะรู้สึกว่ายุ่งยาก แต่เมื่อทำจนเป็นนิสัยแล้ว จะเห็นประโยชน์ของมันอย่างมหาศาลครับ