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

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

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

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

ในสาขา release จะไม่สร้างคุณสมบัติใหม่ มีเพียงการแก้ไขบั๊ก การอัปเดตเวอร์ชันแอปพลิเคชัน การแปลภาษา และเอกสารประกอบ เมื่องานทั้งหมดเสร็จสมบูรณ์ สาขา release จะถูกรวมเข้า main (ทำเครื่องหมายเป็นการเผยแพร่) และกลับไปยัง develop (เพื่อให้การแก้ไขบั๊กไปถึงเวอร์ชันอนาคต)

ตามที่ Atlassian, 2024 กล่าว สาขา release มีความสำคัญอย่างยิ่งสำหรับโปรเจกต์ที่มีรอบการเผยแพร่เป็นประจำ เนื่องจากช่วยให้กระบวนการเผยแพร่สามารถคาดการณ์ได้และมีเสถียรภาพ

วงจรชีวิตของสาขา release

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

1. การสร้าง — จากคอมมิตล่าสุดของ develop จะสร้างสาขาชื่อ release/2.5.0 develop ยังคงรับสาขาคุณสมบัติสำหรับเวอร์ชันถัดไป
2. การเตรียม — ในสาขา release จะอัปเดตเวอร์ชันแอปพลิเคชันใน build.gradle, Info.plist และไฟล์คอนฟิกอื่นๆ
3. การแก้ไขบั๊ก — ข้อผิดพลาดร้ายแรงที่พบระหว่างการทดสอบครั้งสุดท้ายจะได้รับการแก้ไข เฉพาะบั๊กเท่านั้น ไม่มีคุณสมบัติใหม่
4. การทดสอบครั้งสุดท้าย — ทีม QA ทำการทดสอบการถดถอยบนสาขา release บั๊กใหม่จะถูกส่งไปแก้ไขในสาขาเดียวกัน
5. การรวมเข้า main — สาขา release ถูกรวมเข้า main ด้วยแฟล็ก --no-ff แท็กการเผยแพร่ถูกสร้างขึ้น: v2.5.0
6. การรวมเข้า develop — สาขา release ถูกรวมกลับเข้า develop เพื่อให้การแก้ไขบั๊กจากการเผยแพร่ไปถึงการพัฒนาปัจจุบัน
7. การลบ — สาขา release ถูกลบทั้งในเครื่องและระยะไกล เนื่องจากงานสำเร็จแล้ว

ขั้นตอนที่ 6 — การรวมกลับเข้า develop — มักถูกลืม แต่มีความสำคัญอย่างยิ่ง หากไม่มีขั้นตอนนี้ การแก้ไขบั๊กที่ทำในสาขา release จะไม่ไปถึง develop และข้อผิดพลาดเดียวกันอาจปรากฏขึ้นอีกในการเผยแพร่ครั้งถัดไป

ระยะเวลาทั่วไปของขั้นตอนสาขา release

อายุของสาขา release ขึ้นอยู่กับความซับซ้อนของการเผยแพร่และคุณภาพของโค้ดใน develop โดยเฉลี่ยแล้ว การเตรียมการใช้เวลา 2 ถึง 5 วันทำการสำหรับแอปพลิเคชันมือถือขนาดกลาง

สิ่งที่ทำในสาขา release

ในสาขา release จะดำเนินการชุดงานที่จำกัดอย่างเคร่งครัด การเบี่ยงเบนใดๆ จากรายการนี้ละเมิดโมเดล Git Flow และสร้างความเสี่ยงต่อเสถียรภาพของการเผยแพร่

กฎ ห้ามคุณสมบัติใหม่ เป็นกฎที่สำคัญที่สุดในสาขา release หากคุณสมบัติไม่ทันสำหรับการเผยแพร่ ก็รอรอบถัดไป การพยายามผลักดันคุณสมบัติที่ยังไม่เสร็จเข้าไปในสาขา release เป็นสาเหตุหลักของการพลาดกำหนดส่งและบั๊กในระบบจริง

การอัปเดตเวอร์ชันในโปรเจกต์มือถือ

ในสาขา release หมายเลขเวอร์ชันของแอปพลิเคชันจะต้องได้รับการอัปเดต สำหรับ Android คือฟิลด์ versionCode และ versionName ใน build.gradle สำหรับ iOS คือ CFBundleShortVersionString ใน Info.plist

// build.gradle (ระดับแอป) — อัปเดตเวอร์ชันในสาขา release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// สำหรับ iOS — อัปเดต Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

ความแตกต่างระหว่าง release และ hotfix

นักพัฒนามือใหม่มักสับสนระหว่างสาขา release และ hotfix แม้ว่าวัตถุประสงค์จะแตกต่างกันโดยพื้นฐาน การเลือกประเภทสาขาที่ผิดอาจทำให้การแก้ไขที่สำคัญล่าช้าหรือขัดขวางกระบวนการเผยแพร่

• แหล่งที่มา — release สร้างจาก develop, hotfix สร้างจาก main นี่คือความแตกต่างหลักที่กำหนดสิ่งอื่นๆ ทั้งหมด
• ความเร่งด่วน — release มีการวางแผน: ทีมตัดสินใจว่าจะเริ่มเตรียมการเมื่อใด Hotfix เร่งด่วน: ปัญหาในระบบจริงต้องการการแก้ไขทันที
• เนื้อหา — release อาจรวมการแก้ไขหลายรายการและการอัปเดตเวอร์ชัน Hotfix มีเพียงการแก้ไขที่สำคัญเพียงครั้งเดียว
• การรวม — release ถูกรวมเข้า main และ develop Hotfix ก็ถูกรวมเข้า main และ develop เช่นกัน แต่มีความสำคัญสูงกว่า
• อายุ — release มีอายุ 1 ถึง 7 วัน Hotfix มีอายุ 30 นาทีถึง 1 วัน

หากพบข้อผิดพลาดระหว่างการเตรียมการเผยแพร่ (ในสาขา release) — เป็นการแก้ไขบั๊กปกติ หากพบข้อผิดพลาดในระบบจริง (บน main) — เป็น hotfix และสร้างจาก main แม้ว่าสาขา release จะมีอยู่แล้วก็ตาม

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

มาตรฐาน การตั้งชื่อสาขา release ที่เป็นหนึ่งเดียวช่วยให้การนำทางในคลังเก็บข้อมูลง่ายขึ้นและช่วยให้ระบบ CI/CD ตรวจจับโดยอัตโนมัติว่าสาขาเป็นส่วนหนึ่งของกระบวนการเผยแพร่

• release/X.Y.Z — รูปแบบ Git Flow มาตรฐาน โดย X.Y.Z คือเวอร์ชันเผยแพร่ ตัวอย่าง: release/2.5.0
• release/ชื่อ — รูปแบบอื่นด้วยชื่อรหัสการเผยแพร่ ตัวอย่าง: release/merlin
• release/วันที่ — รูปแบบพร้อมวันที่เผยแพร่ ใช้น้อยเนื่องจากเวอร์ชันสำคัญกว่าวันที่ ตัวอย่าง: release/2024-12-01

รูปแบบ release/X.Y.Z เป็นรูปแบบที่ต้องการ เนื่องจากเชื่อมโยงสาขากับหมายเลขเวอร์ชันที่จะกำหนดให้กับการเผยแพร่อย่างชัดเจน ซึ่งช่วยให้การค้นหาและการประมวลผลอัตโนมัติโดยสคริปต์ CI/CD ง่ายขึ้น

กลยุทธ์การรวมกลับเข้า develop

การรวมกลับ (merge back) ของสาขา release เข้า develop เป็นหนึ่งในการดำเนินการที่สำคัญที่สุดและมักถูกมองข้ามบ่อยที่สุด หากไม่มี การแก้ไขบั๊กทั้งหมดที่ทำในสาขา release จะคงอยู่เฉพาะในเวอร์ชันเผยแพร่และไม่ถึงรอบการเผยแพร่ถัดไป

กระบวนการรวมกลับจะดำเนินการหลังจากสาขา release ถูกรวมเข้า main แล้ว ขั้นแรก release ถูกรวมเข้า develop จากนั้นจึงลบ ซึ่งรับประกันว่า develop มีการแก้ไขทั้งหมดที่ทำระหว่างการเตรียมการเผยแพร่

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

บางทีมใช้ rebase แทน merge สำหรับการรวมกลับเพื่อให้ประวัติเป็นเส้นตรง อย่างไรก็ตาม merge ปลอดภัยกว่าสำหรับ develop เนื่องจากไม่ได้เขียนประวัติคอมมิตที่นักพัฒนาคนอื่นอาจใช้งานอยู่แล้ว

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

มาดูวงจรการทำงานกับสาขา release อย่างสมบูรณ์ ตั้งแต่การสร้างจนถึงการลบหลังจากการเผยแพร่แอปพลิเคชันมือถือเวอร์ชัน 2.5.0 สำเร็จ

# 1. สร้างสาขา release จาก develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. อัปเดตเวอร์ชันและแก้ไขบั๊ก
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. แก้ไขบั๊ก (เฉพาะ bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. ส่งสาขา release ไปยังเซิร์ฟเวอร์
git push origin release/2.5.0

# 5. รวม release เข้า main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. รวมกลับเข้า develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. ลบสาขา release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

คำสั่งที่ 5 และ 6 — การรวมสองครั้ง — มีความสำคัญอย่างยิ่ง ขั้นแรก main ได้รับโค้ดการเผยแพร่และแท็ก จากนั้น develop ซิงค์กับการแก้ไขบั๊กจาก release หากข้ามขั้นตอนที่ 6 การแก้ไขจากการเผยแพร่จะไม่ถึงรอบการพัฒนาถัดไป

การทำให้กระบวนการเผยแพร่อัตโนมัติ

สำหรับโปรเจกต์มือถือที่มีการเผยแพร่เป็นประจำ กระบวนการสร้างสาขา release และอัปเดตเวอร์ชันสามารถทำให้เป็นอัตโนมัติผ่านสคริปต์ CI/CD GitHub Actions ช่วยให้สร้างเวิร์กโฟลว์ที่เมื่อคลิกปุ่มจะสร้างสาขา release ด้วยการอัปเดตเวอร์ชันอัตโนมัติ

สำหรับโปรเจกต์มือถือที่มีการเผยแพร่เป็นประจำ กระบวนการสร้างสาขา release และอัปเดตเวอร์ชันสามารถทำให้เป็นอัตโนมัติผ่านสคริปต์ CI/CD GitHub Actions ช่วยให้สร้างเวิร์กโฟลว์ที่เมื่อคลิกปุ่มจะสร้างสาขา release ด้วยการอัปเดตเวอร์ชันอัตโนมัติ

# GitHub Actions — ทำให้การสร้างสาขา release เป็นอัตโนมัติ
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}