Develop Branch ใน Git — คืออะไร วัตถุประสงค์ และหลักการทำงาน

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

Develop Branch (สาขาการพัฒนา) คือสาขาที่มีอายุยาวใน Git Flow ที่ทำหน้าที่เป็นศูนย์กลางสำหรับการรวมโค้ดจากนักพัฒนาทั้งหมด สาขา feature จะถูกรวมเข้าไปหลังจากพัฒนาเสร็จและผ่านการตรวจสอบโค้ด

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

แตกต่างจาก main ที่โค้ดแต่ละเวอร์ชันคือการเผยแพร่ develop มีการเปลี่ยนแปลงอย่างต่อเนื่อง คอมมิตใน develop จะปรากฏขึ้นเมื่อสาขา feature ถูกรวม ซึ่งสามารถเกิดขึ้นได้หลายครั้งต่อวัน

ตามข้อมูลจาก Vincent Driessen, 2010 develop เป็นองค์ประกอบสำคัญของโมเดลการสร้างสาขาที่ประสบความสำเร็จ เนื่องจากแยกงานร่างออกจากเวอร์ชันที่พร้อมเผยแพร่

ความแตกต่างระหว่าง develop และ main branch

การเข้าใจความแตกต่างระหว่าง develop และ main เป็นสิ่งสำคัญสำหรับการทำงาน Git Flow ที่ถูกต้อง สาขาเหล่านี้มีหน้าที่ต่างกันและมีข้อกำหนดความเสถียรที่แตกต่างกัน

การแบ่งเป็น develop และ main ช่วยให้ทีมสามารถรวมโค้ดใหม่ได้อย่างต่อเนื่องโดยไม่เสี่ยงต่อความเสถียรของเวอร์ชันการผลิต นักพัฒนาสามารถเห็นโค้ดของตนใน develop ทันทีหลังจาก PR ได้รับการอนุมัติ แม้กระทั่งก่อนการเผยแพร่อย่างเป็นทางการ

บทบาทของ develop ใน Git Flow

ในโมเดล Git Flow develop อยู่ในตำแหน่งศูนย์กลางระหว่างสาขา feature (แหล่งที่มาของการเปลี่ยนแปลง) และสาขา release (การเตรียมการเผยแพร่) การเข้าใจลำดับชั้นนี้เป็นพื้นฐานของการสร้างสาขาที่มีประสิทธิภาพ

• Feature → Develop — ฟีเจอร์ที่เสร็จสมบูรณ์แต่ละรายการจะถูกรวมใน develop ผ่าน Pull Request พร้อมการตรวจสอบโค้ด
• Develop → Release — เมื่อมีการเปลี่ยนแปลงเพียงพอสำหรับการเผยแพร่ จะสร้างสาขา release จาก develop
• Release → Main + Develop — หลังจากการเตรียมการขั้นสุดท้าย สาขา release จะถูกรวมใน main (เผยแพร่) และกลับไปยัง develop (แก้ไขบั๊ก)
• Hotfix → Main + Develop — การแก้ไขที่สำคัญถูกสร้างจาก main และรวมในทั้งสองสาขา

โครงสร้างนี้รับประกันว่า develop จะมีโค้ดล่าสุดพร้อมฟีเจอร์ใหม่ทั้งหมดเสมอ ในขณะที่ main มีเฉพาะโค้ดการผลิตที่ผ่านการตรวจสอบแล้ว ซึ่งสำคัญโดยเฉพาะสำหรับโปรเจกต์มือถือที่มีรอบการตรวจสอบยาวใน App Store และ Google Play

ความสัมพันธ์ของ develop กับสาขา Git Flow อื่น ๆ

Develop ทำหน้าที่เป็นตัวเชื่อมกลางระหว่างสาขา feature, release และ hotfix การเข้าใจทิศทางการรวมเป็นสิ่งจำเป็นในการป้องกันความขัดแย้งและการสูญเสียคอมมิต

ข้อกำหนดคุณภาพโค้ดใน develop

คุณภาพโค้ด ใน develop ต้องสูง แต่ไม่สมบูรณ์แบบ แตกต่างจาก main ที่ข้อผิดพลาดทุกครั้งหมายถึง hotfix เร่งด่วน develop อนุญาตให้มีข้อบกพร่องเล็กน้อยที่จะแก้ไขก่อนการเผยแพร่

ข้อกำหนดขั้นต่ำสำหรับโค้ดก่อนรวมใน develop:

• การคอมไพล์ — โค้ดต้องคอมไพล์โดยไม่มีข้อผิดพลาด บิลด์ที่พังใน develop ขัดขวางการทำงานของทั้งทีม
• การทดสอบหน่วย — การทดสอบที่มีอยู่ทั้งหมดต้องผ่าน โค้ดใหม่ต้องครอบคลุมโดยการทดสอบอย่างน้อย 70%
• รูปแบบโค้ด — โค้ดต้องเป็นไปตามมาตรฐานการจัดรูปแบบและการตั้งชื่อที่ทีมยอมรับ
• ไม่มี API ที่เลิกใช้ — ไม่อนุญาตให้ใช้เมธอดที่เลิกใช้แล้วในโค้ดใหม่

การตรวจสอบอัตโนมัติในไปป์ไลน์ CI/CD ควรทำงานทุกครั้งที่มีการ push ไปยัง develop หากบิลด์พัง นักพัฒนาที่รับผิดชอบต้องแก้ไขปัญหาภายในหนึ่งชั่วโมงหรือย้อนกลับคอมมิตของตน

การตรวจสอบ CI/CD สำหรับ develop

การตั้งค่า GitHub Actions สำหรับ develop รับประกันว่า PR ทุกรายการผ่านการตรวจสอบอัตโนมัติก่อนรวม ไปป์ไลน์ทั่วไปประกอบด้วยการสร้าง การทดสอบ และ linting

# GitHub Actions — ตรวจสอบ develop หลังการรวม
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

กฎการรวมใน develop

การรวมใน develop ต้องปฏิบัติตามกฎที่เข้มงวดเพื่อรักษาความเสถียรของสาขาการรวม การละเมิดกฎเหล่านี้นำไปสู่ความขัดแย้ง บิลด์ที่พัง และการเสียเวลาของทีม

• ผ่าน Pull Request เท่านั้น — ห้าม push โดยตรงไปยัง develop การเปลี่ยนแปลงทั้งหมดผ่านการตรวจสอบโค้ด
• อย่างน้อยหนึ่งการอนุมัติ — PR ต้องได้รับการอนุมัติจากนักพัฒนาอย่างน้อยหนึ่งคนที่ไม่ได้เกี่ยวข้องกับงาน
• Squash merge — แนะนำให้รวมคอมมิตทั้งหมดของสาขา feature เป็นหนึ่งเดียวเมื่อรวมใน develop เพื่อประวัติที่สะอาด
• PR ต้องเป็นปัจจุบัน — ก่อนรวม PR ต้องได้รับการอัปเดตเมื่อเทียบกับคอมมิตล่าสุดของ develop (rebase หรือ merge)

กฎ PR ต้องเป็นปัจจุบัน มีความสำคัญเป็นพิเศษ หากสาขา feature ถูกสร้างขึ้นเมื่อสัปดาห์ที่แล้วและ develop ขยับไป 50 คอมมิต การรวมโดยตรงอาจนำไปสู่ความขัดแย้งที่ควรแก้ไขในบริบทของ PR มากกว่าใน develop

การป้องกัน develop จากการรวมที่ไม่ถูกต้อง

กฎการป้องกันสาขา คือการตั้งค่าในระดับ GitHub, GitLab หรือ Bitbucket ที่ป้องกันการเปลี่ยนแปลงที่ไม่ถูกต้องใน develop พวกมันรับประกันว่าแม้การ push โดยไม่ตั้งใจจะไม่ทำลายสาขาการรวม

กฎการป้องกันที่แนะนำสำหรับ develop:

• กำหนดให้มี pull request — ห้าม push โดยตรงไปยัง develop การเปลี่ยนแปลงทั้งหมดผ่าน PR เท่านั้น
• กำหนดให้มีการอนุมัติ — อย่างน้อย 1-2 การอนุมัติก่อนรวม PR
• กำหนดให้มีการตรวจสอบสถานะ — ปิดกั้นการรวมหากไปป์ไลน์ CI/CD ไม่ผ่าน
• กำหนดให้เป็นปัจจุบัน — สาขา PR ต้องได้รับการอัปเดตเมื่อเทียบกับ develop ก่อนรวม
• จำกัดการเข้าถึงการ push — จำกัดสิทธิ์การ push ไปยัง develop เฉพาะนักพัฒนาระดับอาวุโส

การตั้งค่าการป้องกัน develop ใช้เวลา 10 นาทีแต่ป้องกันการหยุดทำงานเป็นสัปดาห์ที่เกี่ยวข้องกับสาขาการรวมที่เสียหาย สำหรับโปรเจกต์มือถือที่มีทีมหลายแพลตฟอร์ม นี่มีความเกี่ยวข้องเป็นพิเศษ

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

ลองพิจารณาวันทั่วไปของนักพัฒนา: ตอนเช้าพวกเขาอัปเดต develop สร้างสาขา feature ใหม่ และหลังจากทำงานเสร็จก็รวมการเปลี่ยนแปลงกลับไปยัง develop

# การซิงค์ develop ตอนเช้า
git checkout develop
git pull origin develop

# การสร้างสาขา feature ใหม่จาก develop
git checkout -b feature/add-push-notifications

# กำลังทำงานบนฟีเจอร์...
git add . && git commit -m "Add FCM integration"

# การอัปเดต develop ระหว่างการพัฒนา
git fetch origin develop
git rebase origin/develop

# หลัง PR อนุมัติ — อัปเดต develop ในเครื่อง
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

คำสั่ง git pull ใน develop ดำเนินการสองอย่างพร้อมกัน: git fetch (ดึงคอมมิตใหม่จากเซิร์ฟเวอร์) และ git merge (รวมกับสาขาท้องถิ่น) สำหรับ develop นี่คือวิธีการซิงโครไนซ์มาตรฐาน

การกู้คืน develop หลังจากการรวมที่เสียหาย

หากโค้ดที่ทำให้บิลด์พังเข้าสู่ develop ต้องดำเนินการอย่างรวดเร็ว ทุกชั่วโมงที่พัฒนาหยุดทำงานคืองานที่ถูกขัดขวางของทีมพัฒนาทั้งหมด

หากโค้ดที่ทำให้บิลด์พังเข้าสู่ develop ให้ใช้ git revert เพื่อสร้างคอมมิตใหม่ที่ยกเลิกการเปลี่ยนแปลงที่มีปัญหา อย่าใช้ git reset ใน develop — มันจะเขียนประวัติที่สมาชิกทีมคนอื่นมีอยู่แล้วใหม่

# ค้นหาคอมมิตที่มีปัญหา
git log --oneline develop

# ยกเลิกคอมมิตผ่าน revert (ปลอดภัย)
git revert a1b2c3d

# ส่งการแก้ไขไปยัง develop ระยะไกล
git push origin develop

# ดูการเปลี่ยนแปลงในคอมมิตที่ระบุ
git show a1b2c3d --stat