Git Commit Message Generator: เขียน Conventional Commits ให้ถูกต้องทุกครั้ง

ทุก developer คงเคยเจอโมเมนต์นี้ — stage ไฟล์เรียบร้อย cursor กระพริบรออยู่ใน commit editor แล้วเราก็พิมพ์อะไรประมาณ "fix stuff" หรือ "update code" แค่ให้งานไปต่อได้ หกเดือนถัดมา git log อ่านเหมือนไดอารี่ที่เขียนอย่างเร่งรีบ ไม่มีใคร — รวมถึงตัวเราเอง — บอกได้เลยว่า commit ไหนเพิ่ม feature ตัวไหน แก้ bug และตัวไหนทำ API พัง

Git Commit Message Generator แก้ปัญหานี้ตั้งแต่ต้นทาง เป็นเครื่องมือฟรีที่ทำงานบน browser สำหรับสร้าง Conventional Commits — specification ของ commit message ที่ใช้กันใน Angular, Vue, Next.js และทีม open-source นับพันทีม ไม่ต้องจำ spec ให้เมื่อย แค่เลือก type ใส่ scope อธิบายการเปลี่ยนแปลง ติ๊ก breaking change แล้ว copy commit message ที่จัดรูปแบบสมบูรณ์ไปใช้ได้ทันที

ไม่ต้องสมัครสมาชิก ไม่ต้องติดตั้ง ไม่ต้องรอ AI สร้างเนื้อหา — มีแค่ฟอร์มที่เป็นระเบียบด้านซ้าย และ commit message ตาม spec ด้านขวา

ทำไมต้องใช้ Git Commit Message Generator?

• ถูก spec โดยไม่ต้องท่องจำ — Conventional Commits มีกฎเป็นรูปเป็นร่างเรื่องรูปแบบ header, ชื่อ type และการ mark breaking change เครื่องมือนี้ encode กฎทั้งหมดไว้ให้ message ที่ได้ถูกต้องโดย default
• ครบ 11 commit types ใน dropdown เดียว — feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert ไม่ต้องเดาว่า improvement หรือ update เป็น type จริงหรือเปล่า (ไม่ใช่ครับ)
• จัดการ breaking change ถูกวิธี — แค่ติ๊ก checkbox เดียว ได้ทั้งเครื่องหมาย ! หลัง scope และ footer BREAKING CHANGE: ซึ่งเป็นสิ่งที่ tool ด้าน SemVer ใช้ตัดสินใจว่าจะ bump minor หรือ major
• Live preview + copy ในคลิกเดียว — เห็น message สุดท้ายปรับอัตโนมัติขณะพิมพ์ แล้ว copy ไปใช้กับ git commit หรือใส่ใน pull request ได้ทันที
• ได้ changelog ฟรี ๆ — message ที่อยู่ในรูปแบบ machine-readable ทำให้ tool อย่าง semantic-release, Changesets หรือ standard-version สร้าง changelog และ bump version จาก git history ได้อัตโนมัติ
• ทีมเข้าใจตรงกัน — แชร์เครื่องมือนี้ให้ทีมใช้ แล้ว commit history จะกลายเป็นสิ่งที่ search ได้จริง: git log --grep "^feat(auth)" ทำงานได้ก็ต่อเมื่อทุกคนใช้ format เดียวกัน

ฟีเจอร์เด่น

จุดเด่นของ live preview คือ header จะถูกประกอบจากทุก field ที่กรอก — type(scope)!: subject — ทำให้เห็นทันทีว่าเครื่องหมายตกหล่นหรือวางผิดที่หรือเปล่า รวมถึงช่องว่างหลัง colon ที่หลายคนมักลืม

ส่วน footer tokens มีประโยชน์มากในงานทีม การอ้างอิง issue ใน trailer (Closes: #123) แทนการยัดไว้ใน subject ช่วยให้ header สั้นกระชับ แต่ยังเก็บ link ที่ issue tracker จะ parse อัตโนมัติเวลา merge เข้า default branch

วิธีใช้งาน

1. เปิด Git Commit Message Generator ใน browser
2. เลือก type ที่ตรงกับการเปลี่ยนแปลง — เช่น feat สำหรับ feature ใหม่ หรือ fix สำหรับ bug fix
3. ใส่ scope ระบุส่วนที่กระทบ เช่น auth หรือ api (ไม่บังคับ)
4. เขียน subject ด้วย imperative mood ("add rate limiter" ไม่ใช่ "added rate limiter") และถ้าจำเป็นใส่ body อธิบายเหตุผลเพิ่มเติม
5. ติ๊ก breaking change ถ้าผู้ใช้ต้อง migrate จากนั้นดู live preview แล้วกด Copy — เอาไปวางหลัง git commit เป็นอันเสร็จ

เข้าใจ Conventional Commits

Conventional Commits คือ specification ขนาดเบาที่วางไว้บน Git ธรรมดา ทุก message มีรูปแบบเดียวกัน:

<type>[optional scope][!]: <subject>

[optional body]

[optional footer(s)]

11 types ที่เครื่องมือรองรับ แต่ละตัวสื่อความหมายต่างกัน:

ในทางปฏิบัติมีกฎเชิงโครงสร้างที่สำคัญอยู่ 3 ข้อ ข้อแรก subject ต้องเขียนด้วย imperative mood ยาวราว 50 characters ไม่ขึ้นต้นด้วยตัวพิมพ์ใหญ่ และไม่ปิดท้ายด้วยจุด ข้อสอง body ต้องแยกจาก subject ด้วยบรรทัดว่าง และ wrap ที่ราว 72 characters โดยอธิบาย เหตุผล ของการเปลี่ยนแปลง — เพราะ diff บอก สิ่งที่เปลี่ยน อยู่แล้ว ข้อสาม breaking change ส่งสัญญาณได้ 2 วิธี คือ ! หลัง type/scope (feat(api)!: ...) และ/หรือ footer BREAKING CHANGE: ที่อธิบายวิธี migrate

ผลตอบแทนของการทำตามกฎเหล่านี้คือ automation — release tooling จะ parse git history แล้ว derive version ถัดไปให้เอง: feat trigger minor bump, fix trigger patch bump และ breaking-change marker trigger major bump ส่วน changelog generator จะจัดกลุ่ม entries ตาม type release notes จึงเขียนตัวเอง

ตัวอย่างการใช้งานจริง

ส่งมอบ feature ใหม่

เพิ่งเพิ่ม OAuth2 login เข้าไป เลือก feat scope auth subject add OAuth2 login support แล้วอธิบาย rollout ใน body:

feat(auth): add OAuth2 login support

Replace the legacy session flow with OAuth2 authorization-code
grant. Refresh tokens rotate on use and expire after 14 days
of inactivity.

แก้ regression

null check หลุดไปทำให้ logout พังกับ user ที่ session หมดอายุ เลือก fix scope auth subject resolve crash when session already expired — ได้ patch release + changelog entry ในไม่กี่วินาที

ประกาศ breaking API change

public API เปลี่ยนรูปร่าง ผู้เรียกใช้ต้องอัปเดต code ติ๊ก breaking change แล้วเครื่องมือจะสร้างทั้ง marker และ footer:

feat(api)!: return pagination metadata in list endpoints

List endpoints now return { items, total, cursor } instead of
a bare array, enabling cursor-based pagination.

BREAKING CHANGE: clients reading the array response must
migrate to response.items.

ปิด issue จาก commit

เพิ่ม footer token อย่าง Closes: #482 เพื่อให้ GitHub หรือ Jira ผูก commit เข้ากับ ticket อัตโนมัติเมื่อ merge เข้า default branch — tracker กับ repository history ก็จะ sync กันเสมอ

Best Practices

• ใช้ imperative mood ใน subject — "add", "fix", "drop" — ให้อ่านแล้วรู้สึกว่า "commit นี้จะ add X"
• เคารพกฎ 50/72 — subject ยาวราว 50 characters, body wrap ที่ราว 72 คั่นด้วยบรรทัดว่าง
• scope ควรเล็กและสม่ำเสมอ — scope ควรระบุ module หรือ component (auth, api, ui) และทีมควรตกลงชุด scope ที่ใช้ได้ร่วมกัน
• ใช้ ! อย่างมีสติ — mark breaking change เฉพาะเมื่อผู้ใช้ public interface ต้องปรับตัว งาน refactor ภายในแทบไม่เกี่ยว
• body อธิบาย why ไม่ใช่ what — diff คือบันทึกที่แท้จริงของสิ่งที่เปลี่ยน body เก็บแรงจูงใจ trade-off และ link ที่เกี่ยวข้อง
• หนึ่ง commit = หนึ่งการเปลี่ยนแปลงเชิงตรรกะ — ถ้าต้องใช้ 3 types ใน message เดียว แปลว่าน่าจะเป็น 3 commits ซึ่งเครื่องมือนี้ทำให้การเขียนแต่ละอันดี ๆ ไม่ใช่เรื่องหนักหนาอีกต่อไป

เริ่มเขียน Commit Message ที่ดีขึ้นวันนี้

commit history คือเอกสารที่มีอายุยืน — มันอยู่นานกว่า code review, ticket และบ่อยครั้งกว่าตัวโค้ดเองด้วยซ้ำ การลงแรง 30 วินาทีต่อ commit เพื่อให้มันเป็นระเบียบและ search ได้ คุ้มค่าทุกครั้งที่ต้อง bisect หา bug เขียน release note หรือ onboard สมาชิกใหม่

เปิด Git Commit Message Generator สร้าง commit message ถัดไปแบบมีโครงสร้าง แล้วปล่อยให้ changelog เขียนตัวเอง

เครื่องมือที่เกี่ยวข้อง

• Diff Checker — เทียบข้อความหรือโค้ดสองท่อนก่อน commit
• Markdown TOC Generator — สร้าง table of contents ให้ README ในไม่กี่วินาที
• Regex Tester — ทดสอบและ debug regular expressions พร้อม live highlighting

ขอให้ commit อย่างมีความสุข!