3. การใช้งาน Git ผ่าน GUI แบบขั้นสูง เตรียมพร้อมการทำงานร่วมกับผู้อื่น

Semantic Versioning

Semantic Versioning (SemVer) คือแนวทางปฏิบัติสำหรับกำหนดหมายเลขเวอร์ชั่นของโปรแกรม โดยเมื่อเรากำลังพัฒนาโปรแกรมผ่าน Git ก็จะมี Changelog ไปในตัว ว่าโปรแกรมของเรามีจุดเปลี่ยนแปลงอะไรไปบ้าง จากนั้นเราสามารถใช้ git tag เพื่อกำหนดหมายเลขของเวอร์ชั่นโปรแกรมแต่ละช่วง Commit ได้

โดยจากตัวอย่าง หากเป็นหมายเลขเวอร์ชั่น 2.14.3 จะมีความหมายดังนี้

• Major Version คือหมายเลข 2 หมายถึงโปรแกรมมีการเปลี่ยนแปลงครั้งใหญ่ (Breaking Change) จนอาจจะทำให้ถ้าใครเลือกใช้เวอร์ชั่นก่อนหน้า เปลี่ยนมาใช้เวอร์ชั่นปัจจุบันมีโอกาสพบปัญหาบางอย่างได้ หากไม่ดำเนินการ Migration
• Minor Version คือหมายเลข 14 หมายถึงโปรแกรมมีการเพิ่มเติมคุณสมบัติใหม่ ที่จะไม่กระทบต่อผู้ใช้งานเดิม จึงหมายถึงโปรแกรมนี้มีการเพิ่มเติมคุณสมบัติเสริม 14 ครั้งด้วยกัน
• Patch Version คือหมายเลข 3 หมายถึงโปรแกรมมีปัญหาหรือบัคบางอย่าง ที่ต้องได้รับการแก้ไข จึงหมายถึงโปรแกรมนี้มีการแก้ไขไปแล้ว 3 ครั้งด้วยกัน

อย่างไรก็ตาม นี่เป็นเพียงแนวทางปฏิบัติ เราไม่จำเป็นต้องทำตามเสมอไป เพราะบางโปรแกรมเองก็อาจจะมีจุดมากกว่า 4 ตำแหน่ง หรือใช้คำลงท้าย หรือใช้หมายเลขจำนวนครั้งที่ Build เป็นต้น

Conventional Commits

Conventional Commits คือแนวทางปฏิบัติที่ออกแบบมาเพื่อกำหนดวิธีเขียน Commit Message ที่มีความหมายมากขึ้น โดยกำหนดให้เหมือนเป็นมาตรฐานที่เหล่านักพัฒนาควรใช้งานกัน โดยวิธีการเขียนจะมีรูปแบบดังนี้

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

• <type> ส่วนนี้เราสามารถกำหนดเองได้ แต่ส่วนมากจะใช้คำศัพท์ดังนี้
  • fix: แก้ไขบัค ที่มักจะสัมพันธ์กับ SemVer Patch Version
  • feat: เพิ่มเติมคุณสมบัติ (ย่อมาจาก Feature) ที่มักจะสัมพันธ์กับ SemVer Minor Version
  • BREAKING CHANGE: หรืออาจจะเติม ! หลังจาก Type/Scope ดังตัวอย่าง <type>[optional scope]!: หมายถึงการเปลี่ยนแปลงที่สร้างผลกระทบต่อผู้ใช้งานเดิม ที่มักจะสัมพันธ์กับ SemVer Major Version
  • build: การ Build หรือ Compile ของโปรแกรม
  • chore: งานบ้านทั่วไป เช่น ติดตั้งส่วนเสริม แก้ไขเล็กน้อย
  • ci: งานที่เกี่ยวข้องกับ DevOps
  • docs: งานเอกสาร
  • style: ปรับการออกแบบของหน้าจอโปรแกรม
  • refactor: ปรับปรุงคุณภาพของโค้ด โดยอาจจะยังคงคุณสมบัติเดิม
  • perf: ปรับปรุงประสิทธิภาพของโค้ด โดยอาจจะยังคงคุณสมบัติเดิม
  • test: การอัปเดตชุดทดสอบโปรแกรม
• [optional scope] สามารถใช้คำได้อย่างอิสระ โดยไม่จำเป็นต้องเติมก็ได้ เช่น
  • feat(frontend): สำหรับการเติมคุณสมบัติที่ Frontend
  • feat(backend): สำหรับการเติมคุณสมบัติที่ Backend
  • feat(ui): สำหรับการเติมคุณสมบัติหน้าจอโปรแกรม
  • feat(api): สำหรับการเติมคุณสมบัติที่ API
  • feat(auth): สำหรับการเติมคุณสมบัติที่การเข้าสู่ระบบสมาชิก
• <description> คือส่วนของคำอธิบายโดยสั้นๆของการเปลี่ยนแปลง
• [optional body] และ [optional footer(s)]

ซึ่งตัวข้อความของ Commit เราสามารถเขียนได้หลายบรรทัด และเป็นทางเลือก หากเราไม่ได้ต้องการอธิบายอะไรเชิงลึก เราก็สามารถเขียนบรรทัดเดียวดังตัวอย่างด้านล่างได้ เช่น

• feat: add user profile page
• fix: resolve issue with login redirect
• chore: update project dependencies
• refactor: clean up authentication code
• docs: update API documentation
• feat(api): add user authentication support
• fix(ui): resolve button alignment issue on mobile devices
• chore(deps): update eslint to version 7.32.0
• refactor(auth): improve token validation logic
• docs(readme): add setup instructions

หรือแบบหลายบรรทัด เช่น

fix: resolve issue with login redirect

Fixed a bug where users were incorrectly redirected to the home page after logging in.

Closes #134

fix: correct typo in error message

Corrected a typo in the login error message that was confusing to users.

Fixes #256

โดยในตัวอย่างนี้ส่วนของ Footer ด้านล่างสุดมักจะสัมพันธ์กับ GitHub Issues หรือระบบที่คล้ายกัน สำหรับรายงานปัญหาที่เกิดขึ้นต่างๆ ว่าได้รับการแก้ไขจาก Commit นี้แล้ว

โดยเราจะเห็นว่าควรใช้เป็นภาษาอังกฤษ ที่มีความหมายอย่างกระชับ และไม่จำเป็นต้องใช้หลักการแกรมม่าที่ถูกต้องก็ได้ แต่สุดท้ายแล้ว เราก็สามารถเลือกวิธีการ Commit ในรูปแบบของเราที่ถนัดได้อย่างอิสระ ไม่ได้มีข้อบังคับให้ปฏิบัติตามแต่อย่างใด จะใช้ข้อความเป็นภาษาไทยก็ได้เช่นกัน

Git Flow

Git Flow หรือ Git Workflow เป็นอีกแนวทางปฏิบัติสำหรับการใช้งาน Git โดยที่เกี่ยวกับการใช้ Branch อย่างหลากหลาย และแบ่งตามปัจจัยที่เหมาะสม เพื่อให้ระหว่างการำพัฒนาโปรแกรมเป็นไปอย่างต่อเนื่อง ตรวจสอบการเปลี่ยนแปลงที่ง่ายขึ้นว่างานส่วนใดเสร็จแล้ว งานส่วนใดกำลังพัฒนา และเมื่อพบปัญหาแล้วจะเร่งแก้ไขด่วนอย่างไรไม่ให้กระทบกับโค้ดจากแหล่งที่มา Branch อื่นๆด้วย การออกแบบวิธีการใช้ Git เช่นนี้จะเป็นงานที่เกี่ยวข้องกับ DevOps โดยตรง

ในส่วนนี้ผมจะแนะนำให้ศึกษาอย่างละเอียดจาก https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow แต่อย่างไรก็ตามผมจะสรุปไว้โดยคร่าวๆดังนี้

• Branch จะแบ่งออกเป็นดังนี้
  • main (หรือ master) Branch หลักที่จะต้องมีความเสถียรภาพมากที่สุด สามารถนำไปใช้งานได้จริง สำหรับทุกๆ Commit ภายในนั้น
  • develop คือ Branch เชื่อมรอยต่อระหว่าง main และ feature ต่างๆ
    • บางครั้งทั้ง Git Flow จะมีเพียงแค่ main คู่กับ develop เท่านั้นก็ได้ เมื่องานใหม่เสร็จสิ้นเราจะนำมา Merge จาก develop ไปยัง main
  • feature/* คือ Branch ที่จะตั้งชื่อเป็นไปตามคุณสมบัติที่เรากำลังพัฒนาเพิ่มเติมให้แก่ระบบของเรา เช่น
    • feature/dashboard-ui หน้าจอ Dashboard
    • feature/login-authentication ระบบสมาชิกสำหรับการเข้าสู่ระบบ
    • feature/shopping-cart ระบบตระกร้าสินค้าร้านค้าออนไลน์
  • release คือ Branch เสริมที่ไม่จำเป็น จะใช้หากโปรแกรมมีขั้นตอนเตรียมกระบวนจาก develop การเข้าสู่ main
  • hotfix คือ Branch เร่งด่วนที่เชื่อมกับ main โดยตรง สำหรับเร่งแก้ไขบัคที่เกิดขึ้น
• เมื่อมีงานไหนเสร็จแล้ว เราจะดำเนินการ Merge จากชุด Branch หนึ่ง ไปยัง main จะเป็นปลายทาง
• จากนั้น หากมี Branch ใดต้องการนำเนื้อหาจาก main ไปใช้ต่อ เช่น นำไปต่อกับ feature/* ที่ค้างอยู่ จะแนะนำให้ใช้วิธี Rebase จาก main ไปยัง feature/* ที่ต้องการ เพื่อไม่ให้เกิด Commit ใหม่ที่ทำให้อ่านเส้นทางพัฒนาโปรแกรมยากกว่าเดิม

Continuous Integration and Continuous Delivery/Deployment

Continuous Integration and Continuous Delivery/Deployment (CI/CD) คือกระบวนการระหว่างที่โปรเจกต์มีการเปลี่ยนแปลงอย่างต่อเนื่อง เพื่อดำเนินการบางอย่างโดยอัตโนมัติ หรือส่งมอบนำไปใช้งานจริงอย่างต่อเนื่อง โดยไม่จำเป็นต้องมีบุคคลดูแลเบื้องหลัง

เช่น เมื่อระบบพร้อมใช้งานจริง และนำไป Commit & Push Branch main เรียบร้อยแล้ว หากระบบที่ไม่มี CI/CD อาจจะต้องมีบุคคลสั่งรันอะไรบางอย่าง เพื่อนำไปใช้งานจริง แต่หากมีการตั้งค่า CI/CD ไว้สมบูรณ์แบบ เพียงแค่ Commit & Push ไปเท่านั้น ระบบก็จะเตรียม Deploy นำไปใช้งานจริงได้ทันที จึงเป็นงานที่เกี่ยวข้องกับ DevOps โดยตรง และมักจะเกี่ยวข้องกับการใช้งาน Git

โดยผู้ให้บริการ CI/CD นั้นมีหลายที่อย่างมาก ที่สามารถค้นหาด้วยตนเองผ่าน Google และแหล่งข้อมูลอื่นๆ โดยหลักการใช้งานมักจะเกี่ยวข้องกับ Git เช่น หาก Git Repository นี้มีการ Push Commit จาก Branch อะไรบางอย่างเข้ามา แล้วเราจะดำเนินการอย่างไรต่อ เช่น

• หากมีการ Push Branch main ให้ดำเนินการรัน Build โปรเจกต์และระบบทั้งหมด จากนั้นนำไป Deploy ใช้งานจริงที่ Web Server หลัก
• หากมีการ Push Branch develop หรือ hotfix ทุกครั้ง ให้ดำเนินการรัน Unit Testing เพื่อทดสอบระบบภาพรวมว่ายังสามารถใช้งานได้ถูกต้องที่กำหนดไว้หรือไม่ หรือตรวจสอบคุณภาพของโค้ดว่ามีจุดใดที่นักพัฒนาควรแก้ไขหรือไม่ โดยใช้ Static Code Analysis หรือ Generative AI ต่างๆตรวจสอบและรายผลลัพธ์ไปยังผู้ดูแลโปรเจกต์ทันที
• หากมีการ Push Branch release ทุกครั้ง ให้ดำเนินการรัน Compile และ Prepack สำหรับส่วนที่สำคัญ ก่อนนำไปใช้งานจริง

Git Ignore (.gitignore)

สำหรับส่วนนี้คือการสร้างไฟล์ .gitignore เพื่อละเว้นการติดตามเปลี่ยนแปลงไฟล์ เลี่ยงไม่ให้เกิดการ Commit กับไฟล์หรือโฟลเดอร์เหล่านั้น ส่วนนี้เราสามารถศึกษารายละเอียดเชิงลึกจาก https://www.atlassian.com/git/tutorials/saving-changes/gitignore หรือดูตัวอย่างการใช้งานจริงจาก https://github.com/github/gitignore

สำหรับแนวทางการใช้งานขั้นสูงอื่นๆ แนะนำให้ดูภาคปฏิบัติจาก YouTube เพื่อทำความเข้าใจวิธีการใช้งานคำสั่ง Git เพิ่มเติมต่างๆที่สำคัญ