Conventional Commits: มาตรฐาน Commit Message ที่ทีมควรใช้

Categories

หลายคน Developer มักคิดว่า Commit Message เป็นแค่ข้อความธรรมชาติที่อ่านไม่รู้เรื่อง เช่น “fix”, “update”, หรือสกนโคดที่อ่านคล่องความหมาย หากทีมขนาดใหญ่ใช้ Commit Messages แบบนั้น จะทำให้เห็นอะไรว่าอะไร บทความนี้จะแนะนำ Conventional Commits ซึ่งเป็นมาตรฐานสากลสำหรับการเขียน Commit Messages ที่ชัดเจนและใช้งานได้จริง ทำให้ทีมงานขนาดใหญ่สามารถจัดการ Code ได้อย่างมีประสิทธิภาพ

ปัญหา: Commit Messages ที่อ่านไม่ออก

แรกสำคัญ Commit Messages ที่ไม่มีมาตรฐาน จะทำให้เกิดปัญหาในการทำงานหลายประการ:

  • ตัดสินใจว่า Bug เข้ามาเมื่อไรและเกิดจากไฟล์ไหน โดยอ่าน Changelog อัตโนมัติ
  • ค้นหา Commit ที่เกี่ยวข้องกับปัญหา โดยอ่านจาก Commit Messages
  • ปล่อย Automation Tools เช่น Automatic Changelog generation จาก Commit Messages

Conventional Commits คืออะไร?

Conventional Commits เป็น Specification สากลสำหรับการเขียน Commit Messages ในทีมงาน (Specification v1.0.0) ฉะนี้ช่วยให้ทีมสามารถสร้าง Changelog อัตโนมัติ ตัดสินการแจกจ่าย Release และการใช้ Semantic Versioning ได้อย่างถูกต้อง

รูปแบบของ Conventional Commits

รูปแบบพื้นฐานของ Conventional Commits:

<type>[optional scope]: <description>

เช่น type คือ ประเภทของการเปลี่ยนแปลง scope คือโมดูล หรือส่วนที่เกี่ยวข้อง description คือรายละเอียดสั้นๆ

ประเภท (Types) ที่ใช้บ่อย

ประเภท Type ที่นิยมใช้ใน Conventional Commits:

  • feat: เพิ่มฟีเจอร์ใหม่ (ตัด Version minor ขึ้น)
  • fix: แก้ Bug (ตัด Version patch ขึ้น)
  • docs: แก้ Documentation เช่น README, comments
  • style: แก้ Formatting ไม่กระทบ Logic
  • refactor: Refactor Code ไม่เปลี่ยน Feature หรือ Bug
  • test: เพิ่มหรือแก้ Tests
  • chore: งาน Maintenance เช่น Update dependencies
  • perf: ปรับ Performance เช่น ปรับ Query
  • ci: แก้ CI/CD Configuration

Scope: ระบุส่วนหรือโมดูลที่เกี่ยวข้อง

Scope ให้ข้อมูลว่า Commit นี้สัมพันธ์กับส่วนไหนของโปรเจกต์ ตัวอย่าง:

feat(auth): add OAuth2 login
fix(database): resolve connection timeout issue
docs(api): update endpoint documentation
test(payment): add integration tests for PayPal

Breaking Changes: ประกาศการเปลี่ยนที่ทำลายความเข้ากันได้

หาก Commit มีการเปลี่ยนแปลงที่ไม่รวมความเข้ากันได้ (Breaking Change) จะตัด Version major ขึ้น โดยใช้ 2 วิธี:

feat!: change API response format

BREAKING CHANGE: The response structure has changed from 
{data: {...}} to {result: {...}}

ตัวอย่าง Commit Messages ที่ดีและไม่ดี

ตัวอย่าง GOOD (ดี):

feat(auth): implement JWT token refresh mechanism
fix(api): resolve null reference exception in user service
docs(readme): add installation instructions
test(checkout): add payment gateway integration tests

ตัวอย่าง BAD (ไม่ดี):

fix
update
WIP: asdfgh
FIX BUG IN THE SYSTEM

Automated Changelog ด้วย standard-version และ release-please

ข้อดีของ Conventional Commits คือ สามารถสร้าง Changelog อัตโนมัติได้ จากข้อมูล Commit Messages:

ใช้งาน standard-version

npm install --save-dev standard-version
npm run release

คำสั่งนี้จะ:

  • สร้าง CHANGELOG.md โดยดึง Commits ประเภท feat และ fix
  • อัพเดต package.json version ตาม Semantic Versioning
  • สร้าง Git Tag สำหรับ Release

ใช้งาน release-please

release-please เป็น GitHub Action ที่จัดการ Release อัตโนมัติ

name: Release Please
on:
  push:
    branches:
      - main
jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v3
        with:
          release-type: node
          package-name: my-package

Commitlint: ตรวจสอบ Commit Message อัตโนมัติ

Commitlint สามารถตรวจสอบว่า Commit Message เป็นไปตามมาตรฐาน Conventional Commits โดยใช้ Git Hook:

npm install --save-dev @commitlint/config-conventional @commitlint/cli husky
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
npx husky install
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"'

เมื่อผู้พัฒนาพยายาม Commit ที่ไม่เป็นไปตามมาตรฐาน commitlint จะปฏิเสธและแสดงข้อความแจ้งเตือน

  • ทีมสามารถสร้าง Changelog อัตโนมัติเมื่อ Push ไปยัง Main Branch
  • แต่ละ Release ชัดเจนเกี่ยวกับการเปลี่ยนแปลง ให้ Code Review ทำได้ง่ายขึ้น
  • สามารถอัตโนมัติ Deploy เมื่อติด Release Tag ไปยัง Production Environment

สรุป

Conventional Commits เป็นมาตรฐานที่สำคัญสำหรับ:

  • เพิ่มคุณภาพของ Code ด้วยการเขียน Commit Messages ที่ชัดเจน
  • ง่ายต่อการ Code Review เพราะเข้าใจการเปลี่ยนแปลงได้ชัดเจน
  • อนุญาตให้ใช้ Automated Tools เช่น Changelog Generation, Version Bumping
  • สนับสนุน Semantic Versioning ซึ่งช่วยในการวางแผน Release

จงใช้ Conventional Commits ในทีมงานเพื่อให้ Code ของคุณมีคุณภาพสูง มีความชัดเจน และทีมงาน ผู้ให้บริการโฮสติ้ง Cloud VPS สามารถจัดการ Project ได้อย่างมีประสิทธิภาพ