Git Branch Name Generator: แปลงชื่อ ticket เป็นชื่อ branch ตาม convention
แปลงชื่อ ticket เป็นชื่อ git branch แบบ conventional พร้อม slugify, ticket prefix และการจำกัดความยาว ใช้ฟรี ทำงาน client-side 100% ในเบราว์เซอร์
Table of Contents
Git Branch Name Generator: แปลงชื่อ ticket เป็นชื่อ branch ตาม convention
ทุก repository มักเล่าเรื่องราวของทีมตัวเองให้ฟังเสมอ เปิดรายชื่อ branch ของโปรเจกต์ที่มีวินัย คุณจะเห็นจังหวะที่สม่ำเสมออย่าง feat/JIRA-123-user-login-flow หรือ fix/PRO-87-null-check-on-invoice แต่เปิดโปรเจกต์ที่ไม่มี convention ดูสิ คุณจะเจอซากฟอสซิลของความตั้งใจดี: fix-bug-final-2-REAL, new_fix_try3 ชื่อแบบนี้คือสัญญาณเตือนเรื่องวัฒนธรรมทีม — เป็นหลักฐานว่าการตั้งชื่อเป็นการตัดสินใจเดี่ยว ๆ ที่เกิดขึ้นใต้แรงกดดันของ deadline วันละหลายครั้ง โดยไม่มีมาตรฐานร่วมกันเป็นตัวช่วย
Git Branch Name Generator ตัดการตัดสินใจนั้นทิ้งไปเลย paste ชื่อ ticket ลงไป เลือกประเภทการเปลี่ยนแปลงเช่น feat, fix หรือ chore แล้วเครื่องมือจะสร้างชื่อ branch แบบ kebab-case ที่ผ่านการ slugify มาแล้ว พร้อม ticket prefix อย่าง JIRA-123 (เลือกได้) และการจำกัดความยาว กดครั้งเดียวก็ copy ไปใช้กับ git checkout -b ได้ทันที
เครื่องมือทำงาน client-side 100% ทุกอย่างที่ paste ลงไปจึงไม่เคยออกจากเครื่องของคุณ คู่มือนี้จะพาไปดูวิธีใช้งาน เหตุผลเบื้องหลังแต่ละส่วนของชื่อ branch ที่ดี และวิธีเปลี่ยน naming convention จากหน้า wiki ที่ไม่มีใครอ่าน ให้กลายเป็นนิสัยที่ทั้งทีมทำจริง
ทำไมต้องใช้ Git Branch Name Generator?
- มี consistency โดยไม่ต้องคอยดูแล เครื่องมือเดียวกันสร้างชื่อสไตล์เดียวกันไม่ว่าใครเป็นคนพิมพ์ reviewer เลยไม่ต้องคอยแก้ชื่อ branch และ CI rule ที่เช็ก pattern ก็ไม่ fail อีก
- ไล่ย้อนจาก branch กลับไปหา ticket ได้ เมื่อทุก branch มี ticket ID แนบมาด้วย แค่เหลือบดูรายชื่อ pull request ก็รู้ทันทีว่างานแต่ละชิ้นเป็นของ item ไหนใน backlog
- onboarding เร็วขึ้น สมาชิกใหม่แค่ paste ชื่อ ticket เลือกประเภท แล้ว branch แรกของเขาก็หน้าตาเหมือนของทุกคนในทีม ไม่ต้องไปเรียนรู้ความเชื่อส่วนตัวเรื่องการตั้งชื่อ
- automation สะอาดขึ้น script ที่ parse ชื่อ branch เพื่อหา ticket ID หรือประเภทการเปลี่ยนแปลง ต้องพึ่ง format ที่คาดเดาได้ input ที่ consistent ทำให้ automation เชื่อถือได้ ไม่ใช่ของเปราะบาง
- อ่านง่ายในทุกที่ ชื่อ kebab-case ที่สั้นยังอ่านได้ใน terminal prompt และรายการ PR ซึ่งเป็นจุดที่ชื่อยาว ๆ มักถูกตัดให้เหลือครึ่ง ๆ กลาง ๆ
- ไม่มี friction ไม่มีความเสี่ยง ฟรี ไม่ต้องสมัครสมาชิก และประมวลผลในเครื่องล้วน ๆ เหมาะกับทั้งองค์กรที่มีข้อจำกัดด้านความปลอดภัย
Key Features
| Feature | ทำอะไร | ทำไมจึงสำคัญ |
|---|---|---|
| Type selection | เลือก feat, fix, chore และอื่น ๆ ได้ | ฝังความตั้งใจของการเปลี่ยนแปลงไว้ในชื่อ |
| Kebab-case slugify | แปลงเป็นตัวพิมพ์เล็ก ตัดอักขระที่ไม่ได้ คั่นด้วย hyphen | ชื่อใช้ได้กับทุก git host และทุก OS |
| Ticket prefix | เติม ID อย่าง JIRA-123 ข้างหน้าได้ | เชื่อม branch และ PR กลับไปหา ticket |
| Length limit | จำกัดความยาวชื่อ branch รวม | ชื่อยังอ่านได้ใน prompt และรายการ PR |
| Stopword removal | ตัดคำเติมเต็มอย่าง "the" ออกได้ | ชื่อกระชับขึ้นโดยไม่เสียความหมาย |
| Copy to clipboard | กดครั้งเดียว copy ชื่อที่เสร็จแล้ว | ไม่พิมพ์ผิดตอนย้ายไปใส่ terminal |
ทุกอย่างเกิดขึ้นในเบราว์เซอร์ — ไม่มี API call ไม่มี telemetry — ชื่อ ticket ที่เป็นความลับของลูกค้าจึงปลอดภัย และ output ที่ได้สมบูรณ์พร้อมใช้: สิ่งที่ copy คือสิ่งที่พิมพ์ต่อจาก git checkout -b พอดี โดยจัดการเรื่องช่องว่างและอักขระพิเศษไปให้แล้ว
วิธีใช้งาน
- paste ชื่อ ticket copy มาจาก Jira, Linear, GitHub Issues หรือที่ที่ทีมเก็บงาน — เช่น "Fix login redirect loop on Safari mobile"
- เลือกประเภทการเปลี่ยนแปลง feat สำหรับฟีเจอร์ใหม่, fix สำหรับแก้ bug, chore สำหรับงานบำรุงรักษา หรือประเภทอื่นที่ทีมใช้
- ใส่ ticket prefix พิมพ์ ID จากระบบ track งาน เช่น JIRA-123 เพื่อให้ branch ผูกกับ ticket ของมันเสมอ
- ปรับ options ตั้ง length limit ถ้าทีมชอบชื่อสั้น และเปิด stopword removal ถ้าอยากตัดคำเติมเต็มออกจาก slug
- copy แล้วสร้าง branch กด copy แล้วรัน git checkout -b feat/JIRA-123-fix-login-redirect-loop ก็เริ่มงานได้เลย
ทั้ง flow ใช้เวลาราวสิบวินาที — นั่นแหละคือประเด็น เพราะเมื่อทางที่ถูกต้องเร็วเท่าทางที่ง่าย ทางที่ถูกต้องก็จะชนะเสมอ
Naming Convention ที่ทีมรักษาได้จริง
convention ที่อยู่ได้ยาวต้องมีสี่ส่วน: type prefix, slug, ticket ID (เลือกได้) และเพดานความยาว เครื่องมือนี้บังคับครบทั้งสี่ส่วน
Type prefix บอกความตั้งใจของงาน
ยืมมาจาก conventional commits โดยแต่ละ prefix บอก reviewer ว่าจะเจออะไร: feat/ คือฟีเจอร์ใหม่ที่ผู้ใช้เห็น, fix/ แก้พฤติกรรมที่ผิดอยู่, chore/ คืองานบำรุงรักษาที่ไม่เปลี่ยนพฤติกรรม เช่น bump dependency, refactor/ จัดโครงสร้างใหม่โดยไม่เปลี่ยนพฤติกรรม, docs/ แยกงานเอกสารออกมา และ test/ ทำให้งานเรื่อง coverage มองเห็นและค้นหาได้ แค่ใช้ feat, fix และ chore ก็ได้ประโยชน์ส่วนใหญ่แล้ว: การกรองรายการ PR ตามความตั้งใจกลายเป็นเรื่องง่าย และเครื่องมือจัด release note ก็จัดกลุ่มการเปลี่ยนแปลงให้เองได้
กติกา kebab-case slugify
slug ต้องรอดจากสามสิ่ง: filesystem ของคุณ, git host ของคุณ และความจำของเพื่อนร่วมทีม slugification จัดการเรื่องนี้แบบ deterministic: แปลงทุกอย่างเป็นตัวพิมพ์เล็ก แทนช่องว่างและเครื่องหมายที่ติดกันด้วย hyphen ตัวเดียว ตัดอักขระที่ใช้ใน ref ไม่ได้ออก และเช็ด hyphen ท้ายชื่อ ผลคือ "Fix Login Redirect Loop!" กลายเป็น fix-login-redirect-loop — ใช้ได้ทุกที่และไม่กำกวมแม้จะอยู่ใน URL, คำสั่ง shell หรือช่องกรอง branch
Ticket prefix เพื่อการไล่ย้อน
ticket ID ที่วางอยู่ระหว่างประเภทกับ slug เปลี่ยนทุก branch ให้เป็นลิงก์สองทาง: จาก branch คุณหา acceptance criteria ของ ticket เจอ จาก ticket คุณหาทุก branch, PR และ deployment ที่แตะมันได้ ให้วาง ID ไว้หลังประเภททันที เพื่อให้ทั้งคนและ script ดึงมันออกมาด้วย pattern ง่าย ๆ
Length limit และเหตุผลที่ต้องมี
ชื่อ branch ยาว ๆ ทำร้ายเครื่องมืออย่างจริงจัง terminal prompt ตัดทิ้ง GitHub บีบรายการ PR จนชื่อยาวสองอันเริ่มหน้าตาเหมือนกัน เพดานที่ราว 40 ถึง 60 ตัวอักษรบังคับให้ชื่อเหลือแก่นจริง ๆ: ประเภท, ticket และหัวใจของการเปลี่ยนแปลง
Trade-off ของ stopword removal
การตัดคำเติมเต็มอย่าง "the" และ "a" ทำให้ชื่อสั้นลงแทบไม่เสียข้อมูล: "Fix the bug on the invoice page" กลายเป็น fix-invoice-page-bug แต่ความเสี่ยงคือการตัดแรงเกินไปอาจทำให้ความหมายเบลอ — "test login for admins" กับ "test login for users" ต้องไม่ยุบรวมเป็น slug เดียวกัน ให้เก็บคำใด ๆ ที่แบบความหมายสำคัญไว้เสมอ
ก่อนและหลัง
- "Fix the login redirect loop bug on Safari mobile (JIRA-123)" → fix/JIRA-123-safari-login-redirect-loop
- "Add new feature - export dashboard to PDF and CSV (PRO-87)" → feat/PRO-87-export-dashboard-pdf-csv
- "Update deps + bump build script version, misc cleanup (OPS-45)" → chore/OPS-45-update-deps-build-script
- "REFACTOR: split auth module into services (ARCH-9)" → refactor/ARCH-9-split-auth-module
use cases ในทางปฏิบัติ
workflow กับ Jira และ GitHub Projects
developer หยิบ JIRA-123 ขึ้นมา paste ชื่อ ticket แล้ว branch พร้อม ID ในตัวก็เกิดขึ้น GitHub และ Jira เชื่อม PR อัตโนมัติจากชื่อ branch, คอลัมน์สถานะอัปเดตตอน merge และ sprint board สะท้อนความจริงโดยไม่ต้องอัปเดตมือ
คู่มือ contribution ของ open source
maintainer ที่เขียน format ชื่อ branch ไว้ใน CONTRIBUTING.md ก็ยังได้รับ patch-1 จากคนแวะมาแปะ โดยไม่ได้ตั้งใจก่อกวน — แค่การตั้งชื่อให้ถูก format ต้องแลกกับแรงที่เขาไม่มีแรงจูงใจจะลง การแปะลิงก์เครื่องมือนี้ไว้ในคู่มือช่วยขจัด friction นั้นและทำให้รายชื่อ branch ของ repo ยังอ่านได้
script automation ที่สร้าง branch ให้เอง
script ที่คอยดู tracker แล้วรอ ticket ใหม่ สามารถสร้างชื่อตาม pattern เดียวกัน — ประเภท, ID, slug จากชื่อ ticket และความยาวที่จำกัด — เพื่อสร้าง branch อัตโนมัติ เพราะทุกชื่อเป็น format เดียวที่คาดเดาได้ ชั้น parse ของ automation จึงเรียบง่าย ไม่กลายเป็นกอง regex พิเศษสะสม
Best Practices
- ตกลง convention กันใน CONTRIBUTING.md เขียนรายการ type, กติกา slug และเพดานความยาวลงไป พร้อมแปะลิงก์เครื่องมือ convention ที่อยู่แค่ในหัวใครคนหนึ่งไม่ใช่ convention
- พก ticket ID ไปด้วยเสมอ แม้แต่งานแก้เล็ก ๆ ID ก็คือเส้นด้ายที่ร้อย code, review และบริบทเข้าด้วยกันในอีกหลายเดือนถัดมา
- สั้นแต่บอกเรื่อง หลัง type กับ ID เหลือสามถึงห้าคำที่ใจกลางของงาน ส่วนรายละเอียดให้ ticket จำไว้แทน
- อย่าเปลี่ยนชื่อกลาง PR การ rename หลัง review เริ่มต้น ทำลายลิงก์คอมเมนต์ ประวัติ CI และ checkout ในเครื่องคนอื่น
- ให้เครื่องมือเป็นคนตัดสิน เมื่อโต้เถียงเรื่องชื่อกันเกิดขึ้น ทางแก้ที่เร็วที่สุดคือ "รันผ่าน generator แล้วไปทำงานต่อ"
เริ่มใช้ Git Branch Name Generator วันนี้
การตั้งชื่อ branch ไม่ใช่ปัญหาที่ยากที่สุดของทีม แต่เป็นปัญหาที่คุณต้องแก้วันละหลายสิบครั้ง — ซึ่งทำให้มันเป็นจุดที่ถูกที่สุดในการติดตั้งนิสัยที่ดี เปิด Git Branch Name Generator paste ชื่อ ticket ถัดไปของคุณ แล้ว copy ชื่อที่ reviewer ในอนาคตจะต้องขอบคุณคุณ
เครื่องมือที่เกี่ยวข้อง
- Text Case Converter — แปลง text ระหว่าง UPPERCASE, lowercase, Title Case และอื่น ๆ
- Case Style Converter — สลับระหว่าง kebab-case, snake_case และ camelCase สำหรับ slug ต่าง ๆ
- Username Generator — สร้าง handle ที่ consistent และอ่านง่ายสำหรับบัญชีใหม่
ขอให้รื่นรื่ากับการตั้งชื่อ branch และขอให้รายชื่อ branch ของคุณอ่านเหมือน changelog เสมอ
คำถามที่พบบ่อย
ถ: เครื่องมือส่งชื่อ ticket ของฉันขึ้น server ไหม?
ตอบ: ไม่ generator ทำงานในเบราว์เซอร์ล้วน ๆ ไม่มี input ใดออกจากเครื่องของคุณ จึงปลอดภัยกับชื่อ ticket ที่เป็นความลับ
ถ: generator รองรับประเภทการเปลี่ยนแปลงแบบไหนบ้าง?
ตอบ: ชุด conventional ครบ — feat, fix และ chore — พร้อมประเภททั่วไปอื่นอย่าง refactor, docs และ test เพื่อให้ชื่อ branch ตรงกับหมวด conventional commit ได้เป๊ะ
ถ: ทำไมชื่อ branch ต้องมี ticket ID อย่าง JIRA-123 ด้วย?
ตอบ: ID สร้างลิงก์ถาวรระหว่าง code กับ ticket ต้นทาง ทำให้ reviewer, ผู้ตรวจสอบ และ automation ไล่ branch กลับไปหา requirement ตั้งต้นได้ทันที
ถ: length limit เท่าไหร่ถึงเหมาะสมสำหรับชื่อ branch?
ตอบ: ราว 40 ถึง 60 ตัวอักษรกำลังดีสำหรับทีมส่วนใหญ่ — สั้นพอให้อ่านได้ใน prompt และรายการ PR แต่ยังมีที่พอสำหรับ type, ticket ID และ slug ที่บอกเรื่องได้