กำหนด Label ใน Git ง่ายๆ ด้วย TIPS
![กำหนด Label ใน Git ง่ายๆ ด้วย TIPS](/content/images/size/w960/2023/05/tips-best-practices-for-git-issue-labels.webp)
ถ้าใครใช้ Gitlab หรือ Github หรือ Git repository เจ้าอื่นๆ ก็คงเคยเจอเวลาเราสร้าง Issue แล้วจะมีให้เราสามารถกำหนด Label ลงไปได้
เมื่อจำนวน Issue หรือ Merge requests เพิ่มขึ้นมากมายใน GitLab การติดตามรายการเหล่านั้นก็ยิ่งท้าทายมากขึ้น เราสามารถใช้ Label จัดระเบียบและติดตามรายการงานที่เราสนใจได้ง่ายขึ้น นั้นละหน้าที่ของ Label
![](https://snappytux.com/content/images/2023/05/gitlab-labels.webp)
หลายคนอาจสงสัยว่า แล้วเราจะตั้งชื่อ Label และนำไปใช้ยังไงดี? ถ้าหลงเข้ามาอ่านถึงตรงนี้แล้ว ผมจะมาแนะนำวิธีการที่ผมใช้อยู่ในปัจจุบันตามนี้...
วิธีการตั้งชื่อ Labels
เราจะตั้งชื่อ Label ให้เป็นในรูปแบบหมวดหมู่การใช้งาน
<CATEGORY-NAME>:<CATEGORY-VALUE>
เช่น type:bug
หรือ type:enhancement
หรือ priority:medium
เป็นต้น ซึ่งผมจะใช้วิธีการแบ่งหมวดหมู่ที่เรียกว่า TIPS
TIPS เป็นตัวย่อของ Type, Impact, Priority และ Status หมายความว่าแต่ละ Issue ควรมี Label ที่อธิบายถึง Type, Impact และอื่นๆ ให้ครบ 4 หมวด
แต่ละคำเหล่านั้นหมายความว่าอย่างไร? มาดูกัน
Type:
Issue นี้อยู่ในประเภทไหน จะมีค่าดังนี้
- Deployment: ไว้สำหรับ deploy
- Bug: ระบุว่ามันคือข้อผิดพลาด
- Documentation: ระบุว่าเกี่ยวกับเอกสาร
- Enhancement: มีการใช้งานเพิ่มขึ้นหรือ Features ใหม่เข้ามา
- Security: เกี่ยวกับ OWASP หรือความปลอดภัยอื่นๆ
- Performance: ปรับปรุงให้ดีขึ้น เร็วขึ้น
- Refactoring: ปรับปรุง code ให้มันอ่านได้ง่ายขึ้น ลดการซับซ้อนของ code เดิมลง แต่การทำงานยังถูกต้องเหมือนเดิม
Impact:
ใครได้รับผลกระทบจาก Issue นี้บ้าง? ลูกค้า? ทีมพัฒนา? ทีมการตลาดและลูกค้า? จะมีค่าดังนี้
- Internal: Issue ที่เกิดผลกระทบภายในบริษัทเท่านั้น
- External: Issue ที่เกิดผลกระทบต่อบุคคลอื่นภายนอกบริษัท
Priority:
ระดับความสำคัญของ Issue จะมีค่าดังนี้
- Critical: ทิ้งทุกอย่างแล้วมาทำมันซะ
- High: ควรรีบมาจัดการ
- Medium: ยังอยู่ในแผนงาน
- Low: ทำมันเมื่อเราไม่มีอะไรให้ทำมากกว่านี้
Status:
เป็นการบอกสถานะปัจจุบันของ Issue จะมีค่าดังนี้
- Backlog: เป็น Issue ที่ถูกสร้างขึ้นมาแต่ยังไม่ต้องจัดการในตอนนี้
- In progress: เรากำลังดำเนินการ
- Completed: เสร็จแล้ว
- Investigating: ค้นหาข้อมูลเพิ่มเติมก่อนดำเนินการ
- Testing: ทดสอบก่อนที่จะ Completed
- Code review: อยู่ในช่วงตรวจสอบ Code
ตัวอย่างที่ผมใช้ใน Gitlab
![](https://snappytux.com/content/images/2023/05/git-labels-tips.webp)
เพิ่มเติม
ในบ้าง Repo หรือโปรเจ็คอาจกำหนด Label เพิ่มเติมนอกเหนือจาก TIPS ก็ได้ โดยของผมจะมีประมาณนี้
- Component: ผมเอาไว้ระบุว่า issue นี้เกี่ยวข้องกับ feature หรือ module ไหนของโปรเจ็ค เช่น
Component:User
หรือComponent:Vote
หรือComponent:Dashboard
เป็นต้น - DevOps: ไว้ระบุว่ามันคือหน้าที่ของ DevOps ในการจัดการ เช่น
Devops:Create
หรือDevops:Release
เป็นต้น - Uxui: เพื่อบอกว่าจัดการในส่วนของ design หรือ responsive เช่น
uxui:design
หรือuxui:respnsive
เป็นต้น
อย่าลบ Label ที่เราจะยกเลิกการใช้งาน
การลบ Label ที่คิดว่าจะไม่ใช้งานมันอีกต่อไปแล้ว มันจะไปกระทบต่อ Issue หรือ Merge requset ที่เกี่ยวข้องทั้งหมด สิ่งที่ควรทำคือ
- เติมคำว่า
DEPRECATE_
นำหน้าชื่อ Label เช่นpMm
เราแก้ไขเป็นDEPRECATE_pMm
- บอกให้ทุกคนในทีมทราบเรื่องที่เราจะยกเลิกการใช้งาน Label นี้
- รอหนึ่งเดือนแล้วค่อยกลับมาลบ เพื่อที่คนอื่นๆ จะได้ไม่มีใครนำไปใช้งาน
วิธีนำไปใช้
ในทุกครั้งตอนเราสร้าง Issue ให้นึกถึงคำว่า "TIPS" ขึ้นมาเลย แล้วระบุ Label ตามไปเลย Type > Impact > Priority > Status และ Label อื่นๆ ที่อยากเพิ่ม
จะเห็นว่าในการสร้าง Issue แต่ละครั้งของเราต่อไปก็จะไม่มี Issue ไหนที่ไม่มี Label แล้ว และทุกๆ Issue ก็จะต้องมี TIPS เข้าไปด้วยเสมอ
ลองนำไปปรับใช้ตามกันนะครับ ไม่จำเป็นต้องเหมือนของผมทั้งหมด หรือใครแชร์วิธีกำหนด Label ของตัวเองก็บอกกันมาได้นะ...
ข้อมูลเพิ่มเติม:
- https://seantrane.com/posts/logical-colorful-github-labels-18230/
- https://about.gitlab.com/handbook/marketing/project-management-guidelines/labels/
- https://www.fat.codes/articles/tips-issue-labeling-system/
Comments ()