Conventional Branch 1.0.0

บทสรุป

Conventional Branch หมายถึงธรรมเนียมปฏิบัติในการตั้งชื่อ Branch ของ Git ที่มีโครงสร้างและเป็นมาตรฐาน ซึ่งมีจุดมุ่งหมายเพื่อให้ชื่อ Branch อ่านเข้าใจง่ายและสามารถนำไปปฏิบัติงานต่อได้สะดวกขึ้น เราได้แนะนำคำนำหน้า (Prefix) ของ Branch บางส่วนที่คุณอาจต้องการใช้งาน แต่คุณก็สามารถกำหนดรูปแบบการตั้งชื่อของคุณเองได้เช่นกัน รูปแบบการตั้งชื่อที่สม่ำเสมอจะช่วยให้ระบุประเภทของ Branch ได้ง่ายยิ่งขึ้น

ประเด็นสำคัญ

1. ชื่อ Branch ที่ขับเคลื่อนด้วยวัตถุประสงค์ (Purpose-driven Branch Names): ชื่อ Branch แต่ละชื่อจะระบุวัตถุประสงค์อย่างชัดเจน ทำให้ง่ายต่อนักพัฒนาทุกคนในการทำความเข้าใจว่า Branch นี้มีไว้เพื่ออะไร
2. การทำงานร่วมกับ CI/CD: การใช้ชื่อ Branch ที่สม่ำเสมอสามารถช่วยให้ระบบอัตโนมัติ (เช่น Continuous Integration/Continuous Deployment pipelines) เรียกใช้การทำงานเฉพาะเจาะจงตามประเภทของ Branch ได้ (เช่น การดีพลอยอัตโนมัติจาก Branch สำหรับการปล่อยเวอร์ชัน หรือ Release)
3. การทำงานร่วมกันในทีม: ส่งเสริมการทำงานร่วมกันภายในทีมโดยทำให้วัตถุประสงค์ของ Branch มีความชัดเจน ช่วยลดความเข้าใจผิด และทำให้สมาชิกในทีมสามารถสลับไปมาระหว่างงานต่างๆ ได้ง่ายขึ้นโดยไม่เกิดความสับสน

ข้อกำหนด

คำนำหน้าสำหรับการตั้งชื่อ Branch

ข้อกำหนดของ Branch รองรับคำนำหน้า (Prefixes) ดังต่อไปนี้ และควรจัดวางโครงสร้างเป็น:

<type>/<description>

• main: Branch ของการพัฒนาหลัก (เช่น main, master หรือ develop)
• feature/ (หรือ feat/): สำหรับฟีเจอร์ใหม่ (เช่น feature/add-login-page, feat/add-login-page)
• bugfix/ (หรือ fix/): สำหรับการแก้ไขข้อบกพร่อง หรือ บั๊ก (เช่น bugfix/fix-header-bug, fix/header-bug)
• hotfix/: สำหรับการแก้ไขเร่งด่วน (เช่น hotfix/security-patch)
• release/: สำหรับ Branch ที่กำลังเตรียมการปล่อยเวอร์ชัน หรือ รีลีส (เช่น release/v1.2.0)
• chore/: สำหรับงานที่ไม่เกี่ยวข้องกับโค้ดโดยตรง เช่น การอัปเดตการพึ่งพา (Dependency) หรือเอกสารอ้างอิง (Docs) (เช่น chore/update-dependencies)

กฎขั้นพื้นฐาน

1. ใช้อักขระที่เป็นตัวอักษรและตัวเลขพิมพ์เล็ก เครื่องหมายขีดกลาง และจุด (Use Lowercase Alphanumerics, Hyphens, and Dots): ให้ใช้ตัวอักษรพิมพ์เล็ก (a-z), ตัวเลข (0-9) และเครื่องหมายยัติภังค์หรือขีดกลาง (-) เพื่อแยกคำเสมอ หลีกเลี่ยงการใช้อักขระพิเศษ เครื่องหมายขีดล่าง (Underscores) หรือช่องว่าง สำหรับ Branch ที่เป็นรีลีส สามารถใช้จุด (.) ในคำอธิบายเพื่อแสดงถึงหมายเลขเวอร์ชันได้ (เช่น release/v1.2.0)
2. ห้ามใช้เครื่องหมายขีดกลางหรือจุดติดกัน หรือวางไว้ตำแหน่งหน้าสุดหรือหลังสุด (No Consecutive, Leading, or Trailing Hyphens or Dots): ตรวจสอบให้แน่ใจว่าเครื่องหมายขีดกลางและจุดไม่ได้ปรากฏเรียงติดกัน (เช่น feature/new--login, release/v1.-2.0) และไม่ได้อยู่ตรงจุดเริ่มต้นหรือจุดสิ้นสุดของคำอธิบาย (เช่น feature/-new-login, release/v1.2.0.)
3. รักษาความชัดเจนและกระชับ (Keep It Clear and Concise): ชื่อ Branch ควรอธิบายได้ดีแต่มีความกระชับ โดยระบุจุดประสงค์ของงานได้อย่างชัดเจน
4. รวมหมายเลขทิกเก็ต (Include Ticket Numbers): หากเป็นไปได้ ให้ใส่หมายเลขทิกเก็ต (Ticket number) จากเครื่องมือบริหารจัดการโปรเจกต์ของคุณเข้าไปด้วยเพื่อให้ติดตามงานได้ง่ายขึ้น ตัวอย่างเช่น สำหรับทิกเก็ตหมายเลข issue-123 ชื่อ Branch อาจเป็น feature/issue-123-new-login

รูปแบบไวยากรณ์

รูปแบบไวยากรณ์ Augmented Backus-Naur Form หรือ ABNF ต่อไปนี้ได้กำหนดโครงสร้างเชิงรูปแบบของชื่อ Branch ที่ถูกต้อง:

branch-name     = trunk-branch / prefixed-branch
trunk-branch    = "main" / "master" / "develop"
prefixed-branch = type "/" description
type            = "feature" / "feat" / "bugfix" / "fix"
                / "hotfix" / "release" / "chore"
description     = desc-segment *("-" desc-segment)
desc-segment    = 1*(ALPHA / DIGIT) *("." 1*(ALPHA / DIGIT))
ALPHA           = %x61-7A   ; lowercase a-z
DIGIT           = %x30-39   ; 0-9

หมายเหตุ: ไม่อนุญาตให้ใช้เครื่องหมายขีดกลางหรือจุดติดกัน และไม่อนุญาตให้ใช้เครื่องหมายขีดกลางหรือจุดในตำแหน่งเริ่มต้นหรือตำแหน่งสิ้นสุดของคำอธิบาย

ตัวอย่าง

สรุปท้าย

• การสื่อสารที่ชัดเจน: เพียงแค่เห็นชื่อ Branch ก็ช่วยให้เข้าใจถึงจุดประสงค์ของการเปลี่ยนแปลงโค้ดนั้นๆ ได้อย่างชัดเจน
• รองรับระบบอัตโนมัติ: เชื่อมต่อกับกระบวนการอัตโนมัติได้ง่าย (เช่น เวิร์กโฟลว์ (Workflows) ที่แตกต่างกันสำหรับ feature, release และอื่นๆ)
• การขยายขนาด: ทำงานได้ดีในทีมขนาดใหญ่ที่มีนักพัฒนาหลายคนกำลังปฏิบัติงานหลายส่วนที่แตกต่างกันไปพร้อมๆ กัน

โดยสรุปแล้ว Conventional Branch ถูกออกแบบมาเพื่อปรับปรุงการจัดระเบียบโปรเจกต์ การสื่อสาร และการทำงานแบบอัตโนมัติภายในเวิร์กโฟลว์ของ Git (Git workflows) ให้ดียิ่งขึ้น

คำถามที่พบบ่อย

ทำไมประเภทของ Branch ถึงไม่ละเอียดเท่า Conventional Commits (เช่น build, ci, docs, style, refactor)?

Branch มีความแตกต่างจากการคอมมิต (Commits) — Branch เป็นเพียงสิ่งชั่วคราวและส่วนใหญ่จะถูกใช้งานจนกว่าจะถูกนำไปรวม (Merged) เท่านั้น การแนะนำประเภทของ Branch ให้มีมากเกินไปนั้นถือเป็นสิ่งไม่จำเป็น และจะทำให้ยากต่อการจัดการและการจดจำ

มีเครื่องมือใดบ้างที่สามารถใช้ตรวจสอบได้โดยอัตโนมัติหากสมาชิกในทีมไม่ได้ทำตามข้อกำหนดนี้?

คุณสามารถใช้ commit-check เพื่อตรวจสอบข้อกำหนดของ Branch หรือใช้ commit-check-action หากโค้ดของคุณถูกฝากไว้บน GitHub

ฉันสามารถกำหนดประเภทของ Branch ด้วยตัวเองนอกเหนือจากรายการที่ระบุไว้ได้หรือไม่?

ได้ ข้อกำหนดนี้เป็นเพียงการกำหนดชุดประเภทที่แนะนำไว้ แต่ละทีมสามารถกำหนดประเภทเพิ่มเติมที่ปรับแต่งเองเพื่อให้สอดคล้องกับเวิร์กโฟลว์ของตนได้ อย่างไรก็ตาม สิ่งสำคัญคือต้องจัดทำเอกสารสำหรับประเภทที่ปรับแต่งขึ้นมาใหม่อย่างชัดเจน เพื่อให้สมาชิกทุกคนในทีมและเครื่องมืออัตโนมัติต่างๆ รับทราบตรงกัน

Conventional Branch มีความเกี่ยวข้องกับ Conventional Commits อย่างไร?

Conventional Branch ได้รับแรงบันดาลใจมาจาก Conventional Commits และปฏิบัติตามปรัชญาที่คล้ายคลึงกัน นั่นคือ การนำโครงสร้างที่ทั้งมนุษย์และเครื่องจักรสามารถอ่านได้มาใช้กับข้อมูลเมตา (Metadata) ของ Git ในขณะที่ Conventional Commits เป็นการสร้างมาตรฐานให้กับข้อความการคอมมิต (Commit messages) ตัว Conventional Branch จะเป็นการสร้างมาตรฐานให้กับชื่อ Branch ซึ่งข้อกำหนดทั้งสองนี้ต่างช่วยเสริมซึ่งกันและกันได้อย่างลงตัว

ฉันควรจัดการกับ Branch ที่มีอายุยาวนานอย่าง develop หรือ staging อย่างไร?

Branch สำหรับการรวมโค้ดหรือสำหรับสภาพแวดล้อม (Environment branches) ที่มีอายุการใช้งานยาวนาน ซึ่งเป็นส่วนหนึ่งของข้อกำหนดหลัก (อ้างอิงถึงกฎ trunk-branch ในไวยากรณ์) เช่น main, master หรือ develop จะถูกจัดให้เป็น Branch หลัก (Trunk branches) และไม่จำเป็นต้องมีคำนำหน้า (Prefix) นอกจากนี้ แต่ละทีมยังอาจเลือกที่จะกำหนด Branch ที่มีอายุการใช้งานยาวนานอื่นๆ (ตัวอย่างเช่น staging หรือ production) ให้เป็น Branch ที่มีสถานะเสมือน Branch หลัก (“Trunk-like” branches) ตามธรรมเนียมปฏิบัติได้ แต่สิ่งเหล่านี้ถือเป็นส่วนขยายที่ขึ้นอยู่กับแต่ละทีมซึ่งอยู่นอกเหนือจากข้อกำหนดของรูปแบบไวยากรณ์ อย่างไรก็ตาม ในทุกกรณี Branch เหล่านี้ควรได้รับการตั้งชื่ออย่างสม่ำเสมอในทุกภาคส่วนของโปรเจกต์ของคุณ