Git Tag คืออะไร? วิธีสร้าง Version Tag สำหรับ Release

Categories

Git Tag คือเครื่องมือสำคัญสำหรับการหมายเลข release ใน Git repository ทุกครั้งที่คุณ release software ชุดใหม่ การใช้ Tag ช่วยให้คุณกลับไปดูโค้ด ณ จุดนั้นได้ง่ายดาย ไม่ต้องจำ commit hash ยาวๆ ซึ่งเป็นการปฏิบัติที่ดี (best practice) ในการจัดการ version release สำหรับทีม development ที่ต้องการความชัดเจนและติดตามประวัติ release ได้อย่างเป็นระบบ

ประเภทของ Git Tag

Git มี tag อยู่ 2 ประเภท แต่ละประเภทมีลักษณะและวิธีใช้ที่แตกต่างกัน:

1. Lightweight Tag

Pointer สั้นๆ ไปยัง commit เป็นแค่ชื่อ ไม่มีข้อมูลเพิ่มเติม เหมาะสำหรับใช้งานชั่วคราวหรือประเภทส่วนตัว เนื่องจากไม่มีข้อมูลเช่น ผู้สร้าง วันที่ และข้อความ

# สร้าง lightweight tag
git tag v1.0.0

# ดู tag ที่เป็น lightweight
git tag -l v1.0.0

2. Annotated Tag (แนะนำให้ใช้)

Tag ที่มีข้อมูลครบถ้วน ได้แก่ ชื่อผู้สร้าง, email, วันที่, และข้อความ เหมาะสำหรับ public release เพราะมีข้อมูลมากมายสำหรับติดตาม release history

# สร้าง annotated tag พร้อมข้อความ
git tag -a v1.0.0 -m "Release version 1.0.0 - เพิ่มระบบ login"

# ตัวอย่าง annotated tag
git tag -a v1.1.0 -m "Add dashboard feature and improve UI"
git tag -a v2.0.0 -m "Major redesign - breaking API changes"

คำสั่ง Tag ที่ใช้บ่อย

# ดู tag ทั้งหมด
git tag

# ค้นหา tag ด้วย pattern
git tag -l "v1.*"

# ดูรายละเอียดของ tag
git show v1.0.0

# สร้าง tag ย้อนหลัง (ใส่ tag ให้ commit เก่า)
git tag -a v1.0.0 9fceb02 -m "Tag เก่า"

# ลบ tag ระดับเข้า
git tag -d v1.0.0

# ลบ tag จากหลาย commits
git tag -l | xargs git tag -d  # ลบทั้งหมด (ระวัง!)

ส่ง Tag ไป Remote Repository

โดยเริ่มต้น git push จะไม่ส่ง tag ไป ด้วย ต้องส่งแยกต่างหาก วิธีนี้ช่วยให้คุณควบคุมได้ว่าจะ push tag ไหนเท่านั้น

# ส่ง tag เดียว
git push origin v1.0.0

# ส่ง tag ทั้งหมด
git push origin --tags

# ลบ tag จาก remote
git push origin --delete v1.0.0

# ดู tag ใน remote
git ls-remote --tags origin

Semantic Versioning กับ Git Tag

มาตรฐานการตั้งชื่อ version ตาม Semantic Versioning (SemVer): vMAJOR.MINOR.PATCH เป็นการปฏิบัติที่เป็นที่ยอมรับอย่างกว้างขวาง ช่วยให้ทีม developer และผู้ใช้เข้าใจได้ว่าแต่ละ version มีการเปลี่ยนแปลงอะไรบ้าง

  • MAJOR — พักใหญ่ เปลี่ยน API หรือสร้าง breaking change ตัวอย่าง v1.0.0 ไป v2.0.0
  • MINOR — เพิ่มฟีเจอร์ใหม่โดยไม่ทำลายของเดิม ตัวอย่าง v1.0.0 ไป v1.1.0
  • PATCH — แก้บั๊กโดยไม่เปลี่ยนฟีเจอร์ ตัวอย่าง v1.1.0 ไป v1.1.1
# ตัวอย่างการตั้งชื่อ tag
git tag -a v1.0.0 -m "Initial release"
git tag -a v1.1.0 -m "Add dashboard feature"
git tag -a v1.1.1 -m "Fix dashboard crash bug"
git tag -a v1.2.0 -m "Add payment integration"
git tag -a v2.0.0 -m "Major redesign - breaking API changes"

ใช้ Tag ใน GitHub Releases

เมื่อ push annotated tag ไป GitHub หรือ GitLab คุณสามารถสร้าง Release จาก tag นั้นได้เลย และไม่เพียงแค่นั้น ยังสามารถแนบ release notes และ binary files (แพ็คเกจ) ได้อีกด้วย ซึ่งช่วยให้ผู้ใช้สามารถดาวน์โหลดและติดตั้ง software ได้ง่ายขึ้น

# ขั้นตอนใน GitHub:
# 1. push tag ไป remote
git push origin v1.0.0

# 2. ไปที่ GitHub releases page
# 3. Click "Draft a new release"
# 4. เลือก tag ที่ push ไปแล้ว
# 5. เพิ่ม release notes และ binary files
# 6. Publish release

Tag กับ Git Flow Strategy

ในการใช้ Git Flow ที่มี release อย่างเป็นระบบ การใช้ Git Tag นั้นสำคัญมาก เพื่อระบุเวอร์ชันของแต่ละ release ได้ชัดเจน ดู Git Flow: Branching Strategy สำหรับทีม Developer เพื่อเข้าใจว่า tag ใช้ร่วมกับ Git Flow ได้อย่างไร

Webhooks สำหรับ Auto-Deploy

หลาย CI/CD tools สามารถใช้ Git tag เป็น trigger สำหรับการ deploy อัตโนมัติ ตัวอย่างเช่น เมื่อมี tag ใหม่ GitHub Actions หรือ GitLab CI จะ build และ deploy โดยอัตโนมัติ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการตั้งค่า auto-deploy ดู Webhooks: วิธีตั้งค่า GitHub/GitLab Auto-Deploy

CI/CD Pipeline กับ Git Tag

Git tag มักใช้เป็น trigger ใน CI/CD pipeline เพื่อให้การ release เป็นไปโดยอัตโนมัติและปลอดภัย ดู GitHub Actions: CI/CD ระดับเบื้องต้น เพื่อเรียนรู้วิธีตั้งค่า CI/CD pipeline บน ผู้ให้บริการโฮสติ้ง Cloud Hosting ของเรา

ข้อควรระวังในการใช้ Git Tag

  • ต้องอ่านลิงก์ tag เสมอ (ไม่ลบขึ้น)
  • ใช้ annotated tag สำหรับ public release เท่านั้น
  • ไม่ควร tag บน commit ที่ยังไม่ push ไปยัง main/master
  • ใช้ Semantic Versioning เพื่อความสอดคล้องกับมาตรฐาน
  • ควร tag บน main branch เสมอ ไม่ใช่บน feature branch

สรุป

Git Tag เป็นวิธีมาตรฐานในการหมายเลข version ของ software และเป็นส่วนสำคัญของการจัดการ release ที่มีระเบียบ แนะนำให้ใช้ annotated tag แทน lightweight tag สำหรับ release จริง เพราะมีข้อมูลครบถ้วนกว่า และใช้หลัก Semantic Versioning ในการตั้งชื่อเพื่อให้ทีมและผู้ใช้เข้าใจได้ทันทีว่าแต่ละ version มีการเปลี่ยนแปลงอะไรบ้าง ด้วยการใช้ Git tag อย่างเหมาะสม คุณสามารถจัดการ software release ของ ผู้ให้บริการโฮสติ้ง Cloud VPS หรือบริการอื่นๆ ได้อย่างเป็นมืออาชีพและปลอดภัย