แตก Branch ยังไงให้ไม่ยุ่งเหยิง

ในโลกของการพัฒนาซอฟต์แวร์ที่มีการเปลี่ยนแปลงอย่างรวดเร็ว การจัดการ Git repositories อย่างมีประสิทธิภาพเป็นสิ่งสำคัญอย่างยิ่ง โดยเฉพาะอย่างยิ่งเมื่อทีมของคุณเติบโตขึ้นและโปรเจกต์มีความซับซ้อนมากขึ้น คำถามที่มักพบบ่อย เช่น “งานนี้ต้องสร้าง Branch ใหม่มั้ยครับ ?” หรือ “ทำเสร็จเสร็จแล้ว ผมควร Merge กลับเข้าไปที่ Branch ไหน ?” ปัญหาเกี่ยวกับการใช้งาน Git Branch แบบนี้เราน่าจะพอคุ้นเคยกันมาบ้าง

หากคุณกำลังเผชิญกับปัญหาเหล่านี้ ไม่ต้องกังวลไป! เพราะวันนี้เรามีวิธีการจัดการที่ได้รับการพิสูจน์แล้วว่ามีประสิทธิภาพ นั่นคือ “Git Flow” ซึ่งเป็นแนวทางที่จะช่วยให้การจัดการ Branch ใน Git repository ของคุณเป็นระเบียบ เข้าใจง่าย และมีประสิทธิภาพมากขึ้น

Git Flow คืออะไร และทำไมมันถึงสำคัญ?

Git Flow เป็นแนวคิดในการจัดการ Branch และ Workflow ใน Git ที่ถูกนำเสนอโดย Vincent Driessen ในปี 2010 แนวคิดนี้ได้รับความนิยมอย่างรวดเร็วในชุมชนนักพัฒนา เนื่องมาจากโครงสร้างที่ชัดเจนและเข้าใจง่ายสำหรับการจัดการโปรเจกต์ขนาดใหญ่

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

ข้อดีของ Git Flow

1. จัดระเบียบในการพัฒนา: ด้วยโครงสร้างที่ชัดเจน ทำให้ทีมสามารถทำงานกับ Feature ต่างๆ ได้อย่างเป็นอิสระโดยไม่รบกวนกัน
2. รองรับการทำงานหลาย ๆ อย่างพร้อมกัน: สมาชิกในทีมสามารถทำงานบน Feature ต่างๆ พร้อมกันได้ โดยไม่ต้องกังวลตอนที่จะรวม Branch
3. จัดการ Release ได้อย่างมีประสิทธิภาพ: มี Branch เฉพาะสำหรับการเตรียม Release ทำให้สามารถทำงานบน Version ปัจจุบันและ Version ถัดไปได้พร้อมกัน
4. แก้ไขปัญหาฉุกเฉินได้รวดเร็ว: มี Branch สำหรับการแก้ไขปัญหาเร่งด่วนโดยเฉพาะ

โครงสร้างของ Git Flow

Git Flow แบ่ง Branch ออกเป็นสองกลุ่มหลัก คือ Main Group (กลุ่มหลัก) และ Support Group (กลุ่มสนับสนุน) โดยแต่ละกลุ่มมีบทบาทและหน้าที่เฉพาะต่างกันออกไป

Main Group (กลุ่มหลัก)

1. Main Branch (หรือ Master Branch):
   • เป็น Branch หลักของโปรเจกต์ที่เก็บประวัติการ Release อย่างเป็นทางการ
   • โค้ดใน Branch นี้ควรพร้อมสำหรับการ Deploy ไปยัง Production environment เสมอ
   • ไม่ควรมีการ Commit ลงใน Main Branch โดยตรง
2. Develop Branch:
   • เป็น Branch หลักที่ใช้สำหรับการพัฒนา โดยเป็นที่รวบรวมการเปลี่ยนแปลงทั้งหมดสำหรับ Release ถัดไป
   • เมื่อ Develop Branch มีความเสถียรมากพอและพร้อมสำหรับการ Release จะถูก Merge เข้ากับ Main Branch
   • นักพัฒนาสามารถใช้ Develop Branch เพื่อสร้าง Branch Feature ใหม่ได้

Support Group (กลุ่มสนับสนุน)

1. Feature Branches
   • สร้างขึ้นจาก Develop Branch เพื่อพัฒนา Feature ใหม่หรือทำการปรับปรุงที่มีขนาดใหญ่
   • ควรตั้งชื่อให้สื่อความหมาย เช่น feature/user-authentication, feature/shopping-cart
   • เมื่อพัฒนาเสร็จ จะถูก Merge กลับเข้า Develop Branch (ไม่ใช่ Main Branch โดยตรง)
   • หลังจาก Merge เสร็จ Feature Branch นี้จะถูกลบทิ้ง
2. Release Branches
   • สร้างจาก Develop Branch เมื่อใกล้ถึงเวลา Release
   • ใช้สำหรับการเตรียมความพร้อมก่อน Release เช่น การแก้ไข Bug เล็กๆ น้อยๆ, การปรับแต่ง Config ต่าง ๆ
   • ไม่ควรเพิ่ม Feature ใหม่ใน Branch นี้
   • เมื่อพร้อม Release จะถูก Merge เข้าทั้ง Main และ Develop Branch พร้อมกับการ Tag Version
   • หลังจาก Merge เสร็จ Release Branch นี้จะถูกลบทิ้ง
3. Hotfix Branches
   • สร้างจาก Main Branch เมื่อต้องการแก้ไขปัญหาเร่งด่วนใน Production
   • เป็น Branch เดียวที่แยกออกมาจาก Main Branch โดยตรง
   • หลังจากแก้ไขเสร็จ จะถูก Merge กลับเข้าทั้ง Main และ Develop Branch
   • ควรมีการ Tag Version ใหม่บน Main Branch หลังจาก Merge Hotfix
   • หลังจาก Merge เสร็จ Hotfix Branch นี้จะถูกลบทิ้ง

การนำ Git Flow มาใช้ในทีม (แบบไม่ต้องติดตั้ง Extension)

แม้ว่าจะมี Extension สำหรับ Git Flow ที่ช่วยให้การใช้งานง่ายขึ้น แต่เพื่อความสะดวกในการใช้กับทุกที่ทันที เราสามารถนำหลักการของ Git Flow มาใช้ได้โดยไม่ต้องติดตั้ง Extension เพิ่มเติม เพียงแค่ใช้คำสั่ง Git พื้นฐานเท่านั้นในการจัดการ ลองไปดูตัวอย่างการใช้งานกันต่อ

1. การเริ่มต้นโปรเจกต์

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

# สร้าง develop branch
git checkout -b develop
git push -u origin develop

gitGraph
    commit id: "Initial commit"
    commit id: "Setup project"
    branch develop
    commit id: "Create develop branch"

2. การพัฒนา Feature ใหม่

ทุก ๆ งานที่เราทำให้มองว่าเป็น Feature นึง โดยเราเริ่มงานด้วยการแตก Branch ออกมาจาก develop เป็น Bracnch Feature ที่เรากำลังจะทำ พอทำเสร็จก็รวมกลับเข้า develop

# สร้าง feature branch
git checkout develop
git checkout -b feature/new-feature

# ทำการพัฒนาและ commit
git add .
git commit -m "Implement new feature"

# เมื่อพัฒนาเสร็จ merge กลับเข้า develop
git checkout develop
git merge feature/new-feature
git push origin develop

# ลบ feature branch (optional)
git branch -d feature/new-feature

gitGraph
    commit id: "Initial commit"
    commit id: "Setup project"
    branch develop
    commit id: "Create develop branch"
    branch feature/new-feature
    commit id: "Implement new feature"
    checkout develop
    merge feature/new-feature id: "Merge new feature"

3. การเตรียม Release

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

พอเก็บงานใน release ได้เรียบร้อยแล้วก็ทำการ Merge ไปที่ทั้ง main และ develop โดยที่ใน main ทำการ tag เพื่อเอา Deploy ต่อด้วย

# สร้าง release branch
git checkout develop
git checkout -b release/1.0.0

# ทำการทดสอบและแก้ไข bug เล็กๆ น้อยๆ
git add .
git commit -m "Prepare for release 1.0.0"

# เมื่อพร้อม merge เข้า main และ develop
git checkout main
git merge release/1.0.0
git tag -a 1.0.0 -m "Release version 1.0.0"

git checkout develop
git merge release/1.0.0

# ลบ release branch
git branch -d release/1.0.0

# push การเปลี่ยนแปลงทั้งหมด
git push origin main develop --tags

gitGraph
    commit id: "Initial commit"
    commit id: "Setup project"
    branch develop
    commit id: "Create develop branch"
    commit id: "Develop features"
    branch release/1.0.0
    commit id: "Prepare for release 1.0.0"
    checkout main
    merge release/1.0.0 id: "Release 1.0.0"
    checkout develop
    merge release/1.0.0 id: "Merge release back to develop"

4. การแก้ไข Hotfix

เป็นปกติของซอฟต์แวร์ที่ยังไงก็มี bug เกิดขึ้น และหลายครั้งก็เป็น bug ร้ายแรงที่หลุดรอดจนถูก deploy ไปอยู่ใน production ซึ่งสถานการณ์แบบนี้ต้องการการแก้ไขแบบด่วนที่สุด จึงเป็นที่มาของ Branch hotfix ที่ด่วนสมชื่อ แตกออกมาจาก main โดยตรงได้เป็นกรณีพิเศษเลย แก้เสร็จแล้วก็ merge เข้า main และ develop แล้วก็ต้อง tag เพื่ออัปเดตเวอร์ชันที่เอาไป deploy ไว้ด้วยเหมือนเดิม

# สร้าง hotfix branch
git checkout main
git checkout -b hotfix/critical-bug

# แก้ไขปัญหา
git add .
git commit -m "Fix critical bug"

# merge เข้า main และ develop
git checkout main
git merge hotfix/critical-bug
git tag -a 1.0.1 -m "Hotfix 1.0.1"

git checkout develop
git merge hotfix/critical-bug

# ลบ hotfix branch
git branch -d hotfix/critical-bug

# push การเปลี่ยนแปลงทั้งหมด
git push origin main develop --tags

gitGraph
    commit id: "Release 1.0.0"
    branch develop
    commit id: "Continue development"
    checkout main
    branch hotfix/critical-bug
    commit id: "Fix critical bug"
    checkout main
    merge hotfix/critical-bug id: "Hotfix 1.0.1"
    checkout develop
    merge hotfix/critical-bug id: "Merge hotfix to develop"

ข้อควรระวังและเทคนิคเพิ่มเติม

1. การ Commit ตามความเหมาะสม: จำนวนโค้ดที่ commit แต่ละครั้ง ไม่ควรมากหรือน้อยเกินไป ควรจะแบ่งส่วนที่เพิ่มหรือแก้ไขทีละเรื่อง และทำการ commit ทีละเรื่อง เพื่อให้ติดตามประวัติการเปลี่ยนแปลงได้ง่าย
2. การ Pull จาก Develop เป็นประจำ: ในระหว่างการพัฒนา Feature ควร Pull การเปลี่ยนแปลงจาก Develop Branch เข้ามาใน Feature Branch อยู่เสมอ เพื่อลดโอกาสในการเกิด Conflict เมื่อทำการ Merge
3. การใช้ Pull Request: แม้ว่า Git Flow จะไม่ได้พูดถึง Pull Request แต่การใช้ Pull Request ก่อนการ Merge สามารถช่วยในการ Review Code และตรวจสอบคุณภาพได้
4. การตั้งชื่อ Branch ที่มีความหมาย: ใช้ชื่อที่สื่อความหมายชัดเจนสำหรับ Feature และ Release Branches เช่น feature/add-payment-gateway, release/2.3.0
5. การใช้ Tag อย่างสม่ำเสมอ: ใช้ Tag เพื่อมาร์ค Release Version บน Main Branch ทุกครั้งที่มีการ Release
6. การทำ Documentation: เขียนเอกสารอธิบายวิธีการใช้ Git Flow สำหรับทีม เพื่อให้ทุกคนเข้าใจตรงกันและใช้งานได้อย่างถูกต้อง