กฎพื้นฐานและวิธีตั้งชื่อสำหรับการทำงานกับ Branch หลายคนบน GitHub

ในบทความซีรีส์ที่ผ่านมา เราได้เรียนรู้วิธีการใช้งานพื้นฐานของ GitHub ตั้งแต่การ Fork และ Pull Request เพื่อมีส่วนร่วมในการพัฒนาร่วมกับผู้อื่น การพัฒนาโปรเจกต์คนเดียวหรือการมีส่วนร่วมในโอเพนซอร์สคงไม่ใช่เรื่องน่ากลัวอีกต่อไปแล้วใช่ไหมครับ

ในบทความสุดท้ายของซีรีส์นี้ เราจะมาเน้นเรื่อง "การจัดการ Branch" เพื่อให้การพัฒนาเป็นทีมเป็นไปอย่างราบรื่น เมื่อมีคนหลายคนทำงานใน Repository เดียวกัน หากไม่มีกฎเกณฑ์ก็จะเกิดความสับสนได้ในพริบตา เรามาเรียนรู้กฎพื้นฐานในการจัดการ Branch และหลักการตั้งชื่อที่เข้าใจง่าย เพื่อให้ทุกคนทำงานไปในทิศทางเดียวกันและพัฒนาได้อย่างมีประสิทธิภาพ และมุ่งสู่การเป็นผู้เชี่ยวชาญในการพัฒนาแบบทีมกันเถอะ!

ทำไมต้องมีกฎการจัดการ Branch?

จะเกิดอะไรขึ้นถ้าในทีมไม่มีกฎการสร้าง Branch?

นาย A อาจจะสร้าง Branch ชื่อ `feature-A`, นาย B สร้าง `fix-B`, ส่วนนาย C สร้าง `sato-branch` ทุกคนต่างเริ่มสร้าง Branch ด้วยชื่อตามใจชอบ ซึ่งจะทำให้ไม่มีใครรู้ว่า Branch ไหนใช้ทำงานอะไร ผลลัพธ์คือ Branch ที่ไม่จำเป็นจะถูกสร้างขึ้นมากมาย เกิดข้อผิดพลาดในการ merge บ่อยครั้ง และการพัฒนาจะวุ่นวายถึงขีดสุด

เพื่อป้องกันความโกลาหลเช่นนี้และเพื่อให้การพัฒนาเป็นไปอย่างราบรื่น การมี "กฎการจัดการ Branch (Branching Strategy)" ที่เรียบง่ายและทุกคนในทีมเข้าใจร่วมกันจึงเป็นสิ่งจำเป็นอย่างยิ่ง แม้จะมีกลยุทธ์การแตก Branch ที่มีชื่อเสียงอย่าง "Git-flow" แต่สำหรับผู้เริ่มต้น การเรียนรู้พื้นฐานของ "Feature Branch Workflow" ที่เรียบง่ายกว่าก็เพียงพอแล้ว

ประเภทและบทบาทของ Branch พื้นฐาน

ในการพัฒนาแบบทีมอย่างง่าย เราจะใช้ Branch หลักๆ 2 ประเภท มาทำความเข้าใจบทบาทของแต่ละประเภทกันให้ดี

• Branch `main` (เดิมชื่อ Branch `master`)

  นี่คือ Branch ศักดิ์สิทธิ์สำหรับเก็บ "โค้ดของเวอร์ชันที่ใช้งานจริงซึ่งทำงานได้ปกติเสมอ" จะต้องหลีกเลี่ยงการแก้ไข Branch นี้โดยตรงหรือการนำโค้ดที่ไม่เสถียรเข้ามาปะปนโดยเด็ดขาด

  【กฎ】: ห้ามใครก็ตามทำการ commit หรือ push ไปยัง Branch `main` โดยตรง การเปลี่ยนแปลงทั้งหมดควรถูกนำเข้าผ่าน Pull Request จาก Feature Branch เท่านั้น

• Feature Branch (กิ่งสำหรับฟีเจอร์)

  นี่คือ Branchสำหรับทำงานที่สร้างขึ้นเพื่อทำภารกิจเฉพาะอย่าง เช่น การพัฒนาฟีเจอร์ใหม่, การแก้ไขบั๊ก, หรือการปรับปรุงเล็กๆ น้อยๆ หรือที่เรียกว่า "Topic Branch" โดยจะแตกกิ่งออกมาจาก Branch `main` และเมื่อทำงานเสร็จสิ้นก็จะนำกลับไปรวม (merge) กับ Branch `main` เป็น Branch ที่มีอายุสั้นและจะถูกลบไปเมื่องานเสร็จสิ้น

  【กฎ】: ไม่ว่าจะแก้ไขเล็กน้อยแค่ไหนก็ตาม ต้องสร้าง Feature Branch ใหม่ก่อนเริ่มทำงานเสมอ

กฎการตั้งชื่อ Branch ที่เข้าใจง่าย

เพื่อให้ทุกคนสามารถเข้าใจได้ว่า Feature Branch แต่ละอันใช้ทำอะไร การมีกฎการตั้งชื่อที่สอดคล้องกันจึงเป็นสิ่งสำคัญ โดยทั่วไปมักใช้รูปแบบ "`คำนำหน้า/เนื้อหาของงาน`"

ประเภทของคำนำหน้าและตัวอย่าง:

• feature/: กรณีเพิ่มฟังก์ชันใหม่
  • ตัวอย่าง: feature/add-login-page (การเพิ่มหน้าล็อกอิน)
• fix/: กรณีแก้ไขบั๊ก
  • ตัวอย่าง: fix/correct-header-layout-bug (แก้ไขบั๊กการแสดงผลของส่วนหัว)
• refactor/: กรณีปรับปรุงคุณภาพโค้ดโดยไม่เปลี่ยนแปลงฟังก์ชันการทำงาน (Refactoring)
  • ตัวอย่าง: refactor/optimize-database-query (ปรับปรุงประสิทธิภาพของคำสั่งคิวรีฐานข้อมูล)
• docs/: กรณีแก้ไขเอกสาร (เช่น README.md)
  • ตัวอย่าง: docs/update-installation-guide (อัปเดตขั้นตอนการติดตั้ง)

หากมีการแชร์กฎเช่นนี้ในทีม ทุกคนก็จะสามารถเข้าใจได้ทันทีว่า Branch นั้นๆ กำลังทำอะไรอยู่เพียงแค่ดูจากชื่อ

ปฏิบัติจริง! ขั้นตอนพื้นฐานของการพัฒนาแบบทีม

ต่อไป เรามาดูขั้นตอนพื้นฐานของการพัฒนาแบบทีมตามกฎเหล่านี้พร้อมกับคำสั่งกัน

ขั้นตอนที่ 1: ดึงข้อมูลล่าสุดของ Branch `main`

ก่อนเริ่มทำงาน ต้องอัปเดต Branch `main` ในเครื่องของคุณให้เป็นเวอร์ชันล่าสุดจาก Remote Repository เสมอ ก่อนอื่นให้ย้ายไปที่ Branch `main`

git checkout main

จากนั้น ดึงข้อมูลล่าสุดจากรีโมทมายังเครื่องของคุณ

git pull origin main

ขั้นตอนที่ 2: สร้าง Feature Branch สำหรับทำงาน

จาก Branch `main` ที่อัปเดตล่าสุด ให้สร้าง Branch สำหรับทำงานของคุณขึ้นมา ในครั้งนี้ สมมติว่าเราจะ "เพิ่มฟอร์มติดต่อสอบถาม" แล้วสร้าง Branch กัน

git checkout -b feature/add-contact-form

ขั้นตอนที่ 3: แก้ไข/พัฒนา และทำการ commit

ใน Branch ที่สร้างขึ้นใหม่ ให้คุณแก้ไขหรือเพิ่มโค้ดได้อย่างเต็มที่ เมื่องานเสร็จสิ้นในระดับหนึ่งแล้ว ให้สร้าง commit

git add .

git commit -m "เพิ่มโครงสร้างพื้นฐานของฟอร์มติดต่อ"

ขั้นตอนที่ 4: Push ไปยัง Remote Repository

Push Feature Branch ที่คุณสร้างขึ้นไปยัง Remote Repository นี่เป็นครั้งแรกที่เพื่อนร่วมทีมจะสามารถเห็นงานของคุณได้

git push origin feature/add-contact-form

ขั้นตอนที่ 5: สร้าง Pull Request และรอการรีวิว

เมื่อ push เสร็จสิ้น ให้สร้าง Pull Request ไปยัง Branch `main` บน GitHub ขอให้เพื่อนร่วมทีมรีวิวโค้ดและให้ข้อเสนอแนะ (วิธีการสร้าง Pull Request สามารถดูได้จากบทความที่แล้ว)

ขั้นตอนที่ 6: หลังจาก Merge แล้ว ให้ลบ Branch ที่ไม่จำเป็น

เมื่อ Pull Request ถูก merge เรียบร้อยแล้ว Feature Branch ที่ใช้สำหรับงานนั้นก็ไม่จำเป็นอีกต่อไป เพื่อรักษาความสะอาดของ Repository ควรลบทิ้ง

ขั้นแรก ให้ลบ Remote Branch ซึ่งโดยปกติแล้วสามารถทำได้ง่ายๆ เพียงแค่กดปุ่ม "Delete branch" ที่แสดงขึ้นมาหลังจากการ merge ในหน้า Pull Request ของ GitHub

[ภาพ: ปุ่ม "Delete branch" ที่แสดงขึ้นมาหลังจากการ merge]

จากนั้น ให้ลบ Branch ที่ยังคงอยู่ในเครื่องของคุณด้วย กลับไปที่ Branch `main` ก่อน

git checkout main

แล้วจึงลบ Local Branch ที่ไม่จำเป็นออกไป

git branch -d feature/add-contact-form

เท่านี้วงจรการทำงานก็เสร็จสมบูรณ์ เมื่อจะเริ่มงานใหม่ ก็ให้ทำซ้ำตั้งแต่ขั้นตอนที่ 1

สรุป: กฎง่ายๆ ช่วยทีมได้

เคล็ดลับสู่ความสำเร็จในการพัฒนาแบบหลายคน ไม่ได้อยู่ที่การจำกฎที่ซับซ้อน แต่อยู่ที่การที่ทุกคนปฏิบัติตามกฎง่ายๆ อย่างสม่ำเสมอ เพียงแค่ทุกคนในทีมยึดมั่นในกฎพื้นฐานที่แนะนำในครั้งนี้ ประสิทธิภาพในการพัฒนาก็จะเพิ่มขึ้นอย่างมาก และสามารถหลีกเลี่ยงปัญหาที่ไม่จำเป็นได้

• ปกป้อง Branch `main` อยู่เสมอ
• ทำงานใน Feature Branch เสมอ
• ใช้กฎการตั้งชื่อที่เข้าใจง่ายอย่างเคร่งครัด
• การรวมเข้ากับ `main` ต้องทำผ่าน Pull Request เสมอ
• ลบ Branch ที่ merge แล้วอย่างสม่ำเสมอ

ในซีรีส์แนะนำ GitHub นี้ คุณได้เรียนรู้ตั้งแต่การสร้างบัญชีไปจนถึงขั้นตอนพื้นฐานของการพัฒนาร่วมกัน นี่เป็นก้าวที่ยิ่งใหญ่ในฐานะ Web Creator ขอให้คุณนำความรู้ที่ได้ไปใช้ประโยชน์กับ Git และ GitHub ในโปรเจกต์จริง และหวังว่าชีวิตการพัฒนาของคุณจะสะดวกสบายและสร้างสรรค์ยิ่งขึ้น!