GitFlow ช่วยให้การจัดการ Source code ดีขึ้นอย่างไร
ปัจจุบันหลายๆคนที่ทำงานด้านการเขียนโปรแกรม ผมคิดว่าน่าจะไม่มีใครที่ไม่รู้จัก Git และน่าจะทราบดีว่า Git ช่วยให้การทำ Version Control ง่ายขึ้นแค่ไหน
แต่ในบทความนี้เราจะไม่ได้มาพูดถึงข้อดีของ Git แต่เราจะเล่าให้ฟังว่า 1 ในวิธีการใช้งาน Git ที่ถูกต้อง ทำให้เราทำ Version Control ได้ขึ้นไปอีกได้อย่างไร
ปัญหาที่เกิดจาก Git ที่ไม่มีรูปแบบ
“Git is a distributed version-control system”
ถ้าคนที่เคยใช้งาน Git จะทราบดีว่าจริงๆแล้ว Git เป็นแค่ระบบที่ช่วยเราจัดเก็บ Source code และทำ Version control จาก Change ที่เกิดขึ้น ซึ่งมันจะไม่เกิดปัญหาเลยถ้าเราทำงานร่วมกับโปรแกรมเมอร์แค่ 1–2 คน หรือทำฟีเจอร์พร้อมกันแค่ 1–2 ฟีเจอร์ แต่พอทีมเราเริ่มใหญ่ขึ้น ฟีเจอร์เพิ่มมากขึ้น บทบาทของ GitFlow จะยิ่งสำคัญขึ้น
What is GitFlow?
“GitFlow is a branching model for Git.”
GitFlow ไม่ใช่โปรแกรมที่แตกออกมาจาก Git แต่อย่างใด เป็นแค่เหมือนรูปแบบ, วิธีการใช้ Git อีกวิธีนึงที่ได้รับการยอมรับอย่างแพร่หลายอีกวิธีนึงเท่านั้น โดย GitFlow มีการออกแบบมาเพื่อตอบโจทย์การพัฒนาโปรเจคใหญ่ที่มีโปรแกรมเมอร์ทำงานพร้อมกันหลายๆคน ให้มีการจัดการ Version ไปในทิศทางเดียวกัน
Key Benefits
Parallel Development
การพัฒนาโปรแกรมแบบคู่ขนาน คุณสามารถแตก Feature Branches ออกมาทำ Feature ใหม่ได้ตลอด และ Merge กลับไปที่ Branch หลักเมื่อไหร่ก็ได้ที่ต้องการ ซึ่งทำให้สามารถพัฒนาฟีเจอร์ให้เสร็จแล้วทิ้งไว้ใน Feature Branches นั้นรอวัน UAT / Release ก็ได้
Collaboration
เมื่อคุณมีทีมร่วมพัฒนาในฟีเจอร์เดียวกัน Feature branch ที่กำลังทำอยู่ จะทำหน้าที่กลายเป็น Develop branch (ของฟีเจอร์นั้น) ทันที
Release Staging Area
เมื่อการพัฒนาฟีเจอร์เสร็จสิ้น และมีการ Merge กลับ Develop branch เรียบร้อย คุณสามารถเตรียม Release branches เพื่อการ Release ครั้งหน้า
Support For Emergency Fixes
เมื่อเกิด Bug บน Production คุณสามารถ แตก Hotfix Branches จาก Master Branch เพื่อแก้ไข และ Merge เข้าไปที่ Develop Branch ได้ทันที
Branches
GitFlow จะแบ่ง Branches ออกเป็น 2 กลุ่มหลักๆ
The Main Branches
Master Branch คนที่ใช้งาน Git น่าจะไม่มีใครไม่รู้จัก Branch นี้ โดยเป็นทั้ง Branch ตั้งต้น และเป็น Version ที่อยู่บน Production ด้วย
Develop Branch เป็น Branch ที่เอาไว้รวบรวม Feature Branches ต่างๆ เพื่อเตรียมเป็น Release Branches โดยที่เราจะไม่ Commit ใน Branch นี้โดยตรง แต่จะเป็นผ่านการ Merge ผ่าน Feature Branches แทน
Supporting Branches
Feature branches แน่นอนว่าแตกออกมาจาก Develop Branch เพื่อพัฒนาฟีเจอร์ใหม่โดยเฉพาะ และจะ Merge กลับไปอีกทีเมื่อฟีเจอร์เรียบร้อย แต่ควรจะมีการ Pull Develop Branch อยู่ตลอดเพื่อเลี่ยง Conflict
Release branches เมื่อพัฒนาฟีเจอร์ใหม่ และ Pull ลง Develop Branch เรียบร้อย เราสามารถ สร้าง Release Branches เพื่อทดสอบ และแก้ Bug ได้เลย
Hotfix branches ใช้สำหรับแตกออกมาเพื่อแก้ Bug ที่เกิดบน Production เท่านั้น
How It Work?
ทุกฟีเจอร์จะถูกพัฒนาบน Feature Branches
Feature Branches จะถูกแตกออกจาก Develop Branch และ Merge กลับไปเมื่อพร้อม Release
เมื่อได้กำหนด Release เราจะนำ Develop Branch มา Pull Feature Branch และสร้าง Release Branch
Code บน Release Branch จะถูกนำไป Deploy และทดสอบ ถ้าเจอปัญหาอะไรจะแก้บนนั้น และ Deploy ใหม่เลย ทำไปเรื่อยๆจนกว่า Release จะดีพอ
เมื่อ Deploy ขึ้น Production เรียบร้อย เราจะ Merge Release Branch เข้ากับ Master Branch และ Develop Branch ทั้งคู่
Master Branch จะเป็น Branch ที่เก็บ Code บน Production Commit จะมาจากการ Merge จาก Hotfix Branches หรือ Release Branches เท่านั้น
โดย Hotfix branches จะถูกนำมาใช้ในการ แก้ Bug บน Production
Conclusion
จากที่อธิบายมาข้างบนหลายๆคน อาจจะมองภาพการใช้งาน Git ที่ง่ายขึ้น แต่อย่าลืมว่า รูปแบบที่เล่ามาเป็นเพียงแนวทางที่ดีเท่านั้น
บางทีมอาจจะเหมาะสม แต่บางทีมอาจจะไม่เวิร์ค ซึ่งคนที่บอกได้มีเพียงแค่คนในทีมที่ทำงานร่วมกันเท่านั้น
“GitFlow ไม่ได้แก้ปัญหาการแตก Branch ได้ทุกอย่าง เพียงแต่นำเสนอการแตก Branch แบบมีระบบมากขึ้นเท่านั้น”
