โปรดแตก Branch ก่อนเริ่มงาน (เพื่อสุขภาพจิตที่ดีของทุกคนในทีม)

บทความนี้มาจากที่ผมอยากแนะนำ Front-end มือใหม่ให้รู้จักกับ Git Workflow เพื่อนำไปประยุกต์ใช้ในการทำงานจริง เลยตั้งใจจะเขียนเป็นซีรีส์ "Git Workflow สำหรับ Front-End Dev จาก Zero สู่ Hero ในทีม" และนี่คือบทความสองครับ

ในบทความที่แล้วเรื่อง "เริ่มต้น Git ฉบับทำงานจริง ไม่ใช่แค่ 'Save' แต่คือการเดินทางข้ามเวลาของโค้ด" เราได้ปรับทัศนคติและเรียนรู้พื้นฐานที่แข็งแรงของ Git กันไปแล้ว เรารู้แล้วว่า Commit Message ที่ดีมีหน้าตาเป็นอย่างไร และเข้าใจว่า Git ไม่ใช่แค่ปุ่ม Save แต่คือไทม์แมชชีนของโค้ดเรา

ทีนี้ลองจินตนาการสถานการณ์นี้

คุณกำลังทำฟีเจอร์ใหม่ที่ยิ่งใหญ่และซับซ้อนบนโปรเจกต์ของคุณโดยตรงบน Branch ที่ชื่อ main โค้ดส่วนหนึ่งเสร็จแล้ว แต่อีกหลายส่วนยังเป็นแค่โครงสร้างคร่าวๆ ทันใดนั้นเอง มีโทรศัพท์ด่วนเข้ามาแจ้งว่าพบบั๊ก (Bug) ร้ายแรงบนเว็บที่ใช้งานจริงอยู่ และต้องรีบแก้ไขเดี๋ยวนี้!

คุณมองไปที่โค้ดของคุณ... ชิบ... หายแล้ว main ของคุณตอนนี้ปนเปกันมั่วไประหว่างโค้ดที่ยังทำไม่เสร็จกับโค้ดเดิมที่ดีอยู่แล้ว คุณไม่สามารถปล่อยโค้ดเวอร์ชันนี้เพื่อแก้บั๊กได้ เพราะฟีเจอร์ใหม่ที่ยังพังๆ อยู่จะหลุดไปด้วย นี่คือฝันร้ายที่เกิดขึ้นจริงเมื่อเราทำงานทุกอย่างบนเส้นทางหลักเพียงเส้นทางเดียว และนี่คือเหตุผลว่าทำไมคุณต้องรู้จักการ "แตก Branch"

Branch คืออะไร? ลองนึกถึง "จักรวาลคู่ขนาน"

ถ้าคุณเคยดูหนัง Sci-Fi คุณน่าจะคุ้นเคยกับแนวคิดเรื่องจักรวาลคู่ขนาน (Parallel Universe) ในโลกของ Git ก็เช่นกันครับ

ให้คิดว่า Branch main (หรือบางที่เรียก develop) คือ "จักรวาลหลัก" ของเรา เป็นเวอร์ชันของโค้ดที่เสถียร, สะอาด และพร้อมใช้งานได้เสมอ

เมื่อคุณสร้าง Branch ใหม่ มันก็เหมือนกับการสร้างจักรวาลคู่ขนานที่คัดลอกทุกสิ่งทุกอย่างมาจากจักรวาลหลัก ณ เวลานั้น ในจักรวาลใหม่นี้ คุณมีอิสระเต็มที่ที่จะทดลอง, เปลี่ยนแปลง, รื้อโค้ด, หรือสร้างฟีเจอร์ใหม่ๆ โดยที่ ไม่มีผลกระทบใดๆ ต่อจักรวาลหลักเลย

ถ้าการทดลองของคุณสำเร็จ คุณก็สามารถ "รวม" (Merge) จักรวาลคู่ขนานของคุณกลับเข้ามาในจักรวาลหลักได้ แต่ถ้ามันพังไม่เป็นท่าล่ะ? ก็แค่ทิ้งจักรวาลนั้นไป จักรวาลหลักของคุณก็ยังคงปลอดภัยดีเหมือนเดิม

แล้วทำไมต้องสร้าง Branch?

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

1. เพื่อแยกการพัฒนาฟีเจอร์ใหม่ออกจากโค้ดหลัก คุณสามารถพัฒนาฟีเจอร์ใหม่ที่อาจใช้เวลาเป็นวันหรือเป็นสัปดาห์ได้อย่างสบายใจใน Branch ของมันเอง โดยที่ Branch main ยังคงสะอาดและพร้อมสำหรับการแก้บั๊กฉุกเฉินได้ตลอดเวลา
2. เพื่อจัดการกับงานเร่งด่วน เหมือนสถานการณ์ที่เล่าไปตอนต้น เมื่อมีบั๊กด่วนเข้ามา คุณก็แค่สลับกลับไปที่ main แล้วสร้าง Branch ใหม่สำหรับแก้บั๊กโดยเฉพาะ เช่น fix/urgent-payment-bug แก้เสร็จ, ทดสอบ, แล้วรวมกลับ main เพื่อนำขึ้นใช้งานจริงได้ทันที โดยไม่ต้องรอฟีเจอร์ที่คุณทำค้างไว้
3. เพื่อให้หลายคนทำงานพร้อมกันได้ นี่คือหัวใจของการทำงานเป็นทีม ทุกคนสามารถสร้าง Branch ของตัวเองสำหรับงานที่ได้รับมอบหมาย เช่น feature/user-profile, feature/contact-form แล้วลงมือเขียนโค้ดได้พร้อมกันโดยไม่มีใครเหยียบงานใคร

Feature Branch Workflow ฉบับใช้งานจริง (Step-by-Step)

มาถึงส่วนปฏิบัติกันบ้างครับ ทำให้การแตก Branch เป็นนิสัยสำหรับทุกๆ งาน แล้วชีวิตคุณจะดีขึ้นเยอะ

ขั้นตอนที่ 1: กลับไปที่จุดเริ่มต้นและอัปเดตเสมอ

ก่อนจะเริ่มงานใหม่ทุกครั้ง ให้กลับไปที่ Branch หลักของคุณก่อน (ส่วนใหญ่คือ main หรือ develop) และดึงข้อมูลล่าสุดจาก Server มาเสมอ เพื่อให้แน่ใจว่าคุณเริ่มต้นจากโค้ดเวอร์ชันใหม่ที่สุด

git switch main
git pull origin main

ขั้นตอนที่ 2: สร้าง Branch ใหม่สำหรับงานของคุณ

ใช้คำสั่ง git switch -c เพื่อ "สร้างและสลับ" ไปยัง Branch ใหม่ทันที พร้อมตั้งชื่อ Branch ให้สื่อความหมายว่าคุณกำลังจะทำอะไร

Pro-tip การตั้งชื่อ Branch การใช้ Prefix หรือคำนำหน้าชื่อ Branch เป็นสิ่งที่แนะนำอย่างยิ่ง เช่น feature/, fix/, docs/ จะช่วยให้ทั้งทีม (และตัวคุณเอง) เห็นภาพรวมของโปรเจกต์ได้ง่ายขึ้นจากรายชื่อ Branch ทั้งหมด

ขั้นตอนที่ 3: ลงมือเขียนโค้ดและ Commit ใน Branch ของคุณ

ตอนนี้คุณอยู่ในจักรวาลคู่ขนานของคุณแล้ว จัดการเขียน HTML, CSS, JavaScript หรือโค้ดอื่นๆ ได้เต็มที่ Commit งานของคุณเป็นระยะๆ ใน Branch นี้ได้เลย ทุก Commit จะถูกบันทึกไว้ในประวัติศาสตร์ของ Branch นี้เท่านั้น

# เขียนโค้ด...
git add .
git commit -m "feat: create basic structure for contact form"
# เขียนโค้ดเพิ่ม...
git add .
git commit -m "feat: add form validation for email and required fields"

ขั้นตอนที่ 4: ส่ง Branch ของคุณขึ้นไปบน Remote Server

เมื่อคุณทำงานเสร็จในแต่ละวัน หรือต้องการให้คนอื่นเห็นงานของคุณ ควรจะ Push Branch นี้ขึ้นไปเก็บไว้บน Remote Server (เช่น GitHub, GitLab) ด้วย

git push -u origin feature/add-new-contact-form

(คำสั่ง -u เป็นการบอก Git ให้จำไว้ว่า Branch นี้บนเครื่องเรา ผูกกับ Branch ชื่อเดียวกันบน Server ครั้งต่อไปเราจะพิมพ์แค่ git push ได้เลย)

เมื่อทำเสร็จแล้ว... แล้วยังไงต่อ? ตอนนี้โค้ดสุดเจ๋งของเรายังคงอยู่ใน Branch แยก แล้วเราจะเอามันกลับไปรวมกับ main ได้อย่างไร?

บทสรุป

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

ในบทความถัดไป เราจะมาพูดถึงขั้นตอนสุดท้ายของ Workflow นี้ นั่นคือการ "รวมโค้ด" กลับสู่จักรวาลหลักด้วย git merge และวิธีรับมือกับปีศาจที่ทุกคนต้องเจออย่างน้อยหนึ่งครั้งในชีวิต... Merge Conflict ครับ!