Feature Branch ใน Git: คืออะไร วิธีสร้างและทำงานกับสาขา

Feature Branch ใน Git คืออะไร

Feature Branch (สาขาฟีเจอร์) เป็นสาขาชั่วคราวใน Git ที่สร้างจาก develop เพื่อพัฒนาฟังก์ชันเฉพาะ แตกต่างจากสาระสำคัญที่มีอายุยาวนานอย่าง main และ develop สาขา feature จะมีอายุจำกัด — ตั้งแต่ไม่กี่ชั่วโมงจนถึงไม่กี่สัปดาห์

เป้าหมายหลักของ feature branch คือการแยกการเปลี่ยนแปลงที่เกี่ยวข้องกับงานหนึ่งออกจากโค้ดที่เหลือ นักพัฒนาสามารถทดลอง ทำคอมมิตจำนวนมาก และแม้กระทั่งทำให้โค้ดเสียหายในสาขาของตนเองได้ โดยไม่ส่งผลกระทบต่อการทำงานของสมาชิกคนอื่นในทีม

เมื่อการพัฒนาเสร็จสมบูรณ์ สาขา feature จะถูกรวมกลับไปยัง develop ผ่าน Pull Request พร้อมการตรวจสอบโค้ดที่บังคับ หลังจากการรวม สาขามักจะถูกลบเพื่อให้คลังเก็บสะอาด

ตามข้อมูลจาก Vincent Driessen, 2010 โมเดล Git Flow กับสาขา feature กลายเป็นมาตรฐานอุตสาหกรรมเนื่องจากการแบ่งหน้าที่รับผิดชอบที่ชัดเจนระหว่างสาขาประเภทต่าง ๆ

เวิร์กโฟลว์กับ Feature Branch

เวิร์กโฟลว์ กับ feature branch ประกอบด้วยลำดับขั้นตอนที่นักพัฒนาดำเนินการสำหรับแต่ละฟีเจอร์ใหม่ กระบวนการนี้ช่วยลดความขัดแย้งในการรวมและรับประกันการควบคุมคุณภาพโค้ด

1. การสร้างสาขา จากคอมมิตล่าสุดของ develop นักพัฒนาสลับไปยัง develop อัปเดตและสร้างสาขา feature ใหม่
2. การพัฒนาและคอมมิต ในสาขา feature นักพัฒนาเปลี่ยนแปลง ทำคอมมิตพร้อมคำอธิบายที่ชัดเจน และพุชสาขาไปยังคลังเก็บระยะไกลเป็นระยะ
3. การซิงโครไนซ์กับ develop — ระหว่างพัฒนา สาขาหลักอาจก้าวไปข้างหน้า นักพัฒนาทำ rebase หรือ merge develop เข้าสู่สาขา feature ของตน
4. การสร้าง Pull Request — เมื่อฟีเจอร์พร้อม นักพัฒนาเปิด PR เพื่อตรวจสอบโค้ด ทีมตรวจสอบโค้ดและแสดงความคิดเห็น
5. การรวมและลบ — หลังอนุมัติ PR สาขาจะถูกรวมเข้าสู่ develop และลบทั้งในเครื่องและระยะไกล

การซิงโครไนซ์กับ develop เป็นประจำ มีความสำคัญอย่างยิ่ง ยิ่งสาขา feature มีอายุยืนนานโดยไม่รวมการเปลี่ยนแปลงจาก develop โอกาสเกิดความขัดแย้งในการรวมครั้งสุดท้ายก็ยิ่งสูงขึ้น

ความถี่ในการซิงโครไนซ์สาขา feature

กฎการตั้งชื่อสาขา feature

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

• feature/ชื่อ — คำนำหน้า feature/ ใช้ใน Git Flow แบบคลาสสิก ตัวอย่าง: feature/added-auth-module
• feature/JIRA-123-คำอธิบาย — การเชื่อมโยงกับหมายเลขงานในระบบติดตาม ตัวอย่าง: feature/PROJ-42-add-login
• feature/ประเภท/ชื่อ — รูปแบบขยายพร้อมระบุประเภทงาน ตัวอย่าง: feature/feat/analytics-dashboard

การใช้ ID งาน จาก JIRA, Trello หรือระบบอื่นเป็นแนวปฏิบัติที่ดีที่สุด โดยจะเชื่อมโยงโค้ดกับงานโดยอัตโนมัติและทำให้การค้นหาสาขาผ่าน git log ง่ายขึ้น

กระบวนการ Pull Request

Pull Request (หรือ Merge Request ใน GitLab) เป็นคำขอเพื่อรวมสาขา feature เข้าสู่ develop PR ไม่ใช่แค่การดำเนินการทางเทคนิค แต่เป็นกระบวนการตรวจสอบโค้ดของทีมที่ปรับปรุงคุณภาพโค้ดและเผยแพร่ความรู้ภายในทีม

PR ที่ดีประกอบด้วยหัวข้อพร้อมคำอธิบายสั้น ๆ ของงาน ลิงก์ไปยังตั๋ว และคำอธิบายการเปลี่ยนแปลง นักพัฒนาควรระบุว่าทำอะไรไปบ้าง ไฟล์ใดถูกเปลี่ยนแปลง และมีความเสี่ยงที่อาจเกิดขึ้นกับส่วนอื่น ๆ ของโปรเจกต์หรือไม่

ทีมตรวจสอบโค้ดใน PR แสดงความคิดเห็น ขอให้เปลี่ยนแปลง (change requests) และอนุมัติการรวม (approve) หลังอนุมัติ จะดำเนินการ merge หรือ squash merge

เวลาเฉลี่ยในการตรวจสอบ PR ในการพัฒนาแอปมือถืออยู่ที่ 4 ถึง 24 ชั่วโมง ไลบรารี Danger ทำให้การตรวจสอบบางส่วนเป็นอัตโนมัติ โดยเรียกใช้ linters และทดสอบโดยตรงใน PR

คำแนะนำในการสร้าง PR ที่ดี

• ขนาด — ไม่เกิน 300-400 บรรทัดของการเปลี่ยนแปลง PR ขนาดใหญ่ตรวจสอบยาก คุณภาพการตรวจสอบลดลง
• PR หนึ่ง — งานหนึ่ง — หลีกเลี่ยงการผสมการเปลี่ยนแปลงที่ไม่เกี่ยวข้องในคำขอเดียว
• ภาพหน้าจอ — สำหรับการเปลี่ยนแปลง UI ให้แนบภาพหน้าจอก่อนและหลัง
• การทดสอบ — สำหรับฟังก์ชันใหม่ เขียนการทดสอบหน่วยและรวมไว้ใน PR

กลยุทธ์การรวมสาขา feature

หลังอนุมัติ PR สาขา feature สามารถรวมเข้าสู่ develop ได้หลายวิธี การเลือก กลยุทธ์การรวม ส่งผลต่อประวัติคอมมิตและความสามารถในการย้อนกลับการเปลี่ยนแปลง

• Merge commit — สร้างคอมมิตการรวม โดยรักษาประวัติคอมมิตทั้งหมดของสาขา feature ประวัติยังคงสมบูรณ์ แต่กราฟสาขาซับซ้อนขึ้น
• Squash merge — รวมคอมมิตทั้งหมดของสาขา feature เป็นคอมมิตเดียวและเพิ่มเหนือ develop ประวัติสะอาดขึ้น แต่ข้อมูลเกี่ยวกับคอมมิตระหว่างกลางหายไป
• Rebase and merge — เขียนคอมมิตของสาขา feature ใหม่เหนือคอมมิตล่าสุดของ develop และรวมโดยไม่มีคอมมิตเพิ่มเติม ประวัติยังคงเป็นเส้นตรง

สำหรับโปรเจกต์มือถือที่ออกเวอร์ชันบ่อย squash merge มักถูกใช้มากที่สุด: ให้ประวัติที่สะอาดใน develop ในขณะที่รายละเอียดการพัฒนายังคงอยู่ในคำอธิบาย PR และงานในระบบติดตาม

ข้อผิดพลาดทั่วไปในการทำงานกับ Feature Branch

แม้แต่นักพัฒนาที่มีประสบการณ์ก็ทำผิดพลาดเมื่อทำงานกับสาขา feature การรู้ปัญหาทั่วไปช่วยหลีกเลี่ยงการเสียเวลาและข้อมูล

• สาขามีอายุยืนนานเกินไป — สาขา feature มีอายุเกิน 2-3 สัปดาห์โดยไม่ซิงโครไนซ์กับ develop ทำให้เกิดความขัดแย้งในการรวมจำนวนมาก
• คอมมิตพร้อมคำอธิบายไม่ชัดเจน — ข้อความเช่น “fix” หรือ “update” ไม่ได้อธิบายสิ่งที่เปลี่ยนแปลงและเหตุผล
• การผสมงาน — ในสาขา feature เดียวกัน มีการพัฒนาฟังก์ชันที่ไม่เกี่ยวข้องสองอย่าง ทำให้ไม่สามารถย้อนกลับแบบเลือกได้
• ขาดการซิงโครไนซ์ — นักพัฒนาไม่ทำ git fetch และไม่อัปเดต develop ทำให้เกิดความขัดแย้งเมื่อรวมครั้งสุดท้าย

วิธีที่ดีที่สุดในการหลีกเลี่ยงปัญหาเหล่านี้คือการตกลงกฎการทำงานเมื่อเริ่มต้นโปรเจกต์และใช้การตรวจสอบอัตโนมัติในไปป์ไลน์ CI/CD

ตัวอย่างคำสั่งสำหรับทำงานกับ Feature Branch

พิจารณาสถานการณ์จริง: นักพัฒนาเริ่มฟีเจอร์การยืนยันตัวตนใหม่ในแอปมือถือ เขาสร้างสาขา feature ทำงานบนโค้ดและทำงานให้เสร็จด้วย Pull Request

# อัปเดต develop และสร้างสาขา feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# ทำงานบนฟีเจอร์: คอมมิต
git add src/ui/login/
git commit -m "Add login screen layout"

# พุชสาขา feature ไปยังเซิร์ฟเวอร์
git push origin feature/add-login-screen

# ซิงโครไนซ์กับ develop (rebase)
git fetch origin develop
git rebase origin/develop

# หลังอนุมัติ PR: อัปเดต develop ท้องถิ่นและลบสาขา
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

คำสั่ง git branch -d จะลบสาขาก็ต่อเมื่อการเปลี่ยนแปลงของมันถูกรวมเรียบร้อยแล้วเท่านั้น หากสาขายังไม่ถูกรวม Git จะแนะนำให้ใช้ git branch -D สำหรับการลบแบบบังคับ — ใช้แฟล็กนี้ด้วยความระมัดระวัง

การตรวจสอบอัตโนมัติในสาขา feature

ไปป์ไลน์ CI/CD ควรทำงานสำหรับทุกสาขา feature ก่อนสร้าง PR ซึ่งช่วยให้ตรวจพบปัญหาในระยะเริ่มต้น ก่อนที่โค้ดจะถึงการตรวจสอบของนักพัฒนาคนอื่น

# GitHub Actions สำหรับตรวจสอบสาขา feature
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

ไปป์ไลน์ตรวจสอบว่าโค้ดคอมไพล์ได้ การทดสอบผ่าน และรูปแบบโค้ดเป็นไปตามมาตรฐานของทีม หลังจากผ่านการตรวจสอบทั้งหมดแล้วเท่านั้นจึงจะสามารถสร้าง Pull Request ได้