Main และ Master Branch ใน Git: คืออะไรและทำไมต้องมีสาขาหลัก

Main / Master Branch ใน Git คืออะไร

Main Branch (หรือ Master — ขึ้นอยู่กับการตั้งค่ารีโพสิทอรี) คือสาขาเริ่มต้นที่สร้างขึ้นเมื่อเริ่มต้นรีโพสิทอรี Git ใดๆ เป็นสาขาหลักของโปรเจกต์และมีโค้ดพร้อมสำหรับการปรับใช้ในการผลิต

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

หลักการสำคัญ: main ต้องมีความเสถียรเสมอ หากพบข้อผิดพลาดใน main นั่นหมายความว่าจำเป็นต้องมี hotfix ด่วนนอกคิว ดังนั้นในโปรเจกต์มืออาชีพ main ได้รับการปกป้องจากการเปลี่ยนแปลงโดยไม่ได้ตั้งใจด้วยกฎการป้องกันสาขา

ตาม Git Book main ไม่ใช่สาขาพิเศษที่มีคุณสมบัติเฉพาะ แต่เป็นการอ้างอิงปกติไปยัง commit ที่ถือว่าเป็นหลักตามธรรมเนียม Git ไม่แยกความแตกต่างระหว่าง main และสาขาอื่นๆ ในระดับระบบ

การเปลี่ยนจาก master เป็น main

ในอดีต สาขาเริ่มต้นใน Git ถูกเรียกว่า master ในเดือนมิถุนายน 2020 การเคลื่อนไหว Black Lives Matter ดึงความสนใจไปที่คำว่า master และ slave ในอุตสาหกรรม IT GitHub ประกาศการเปลี่ยนไปใช้คำว่า main สำหรับสาขาเริ่มต้น

ตั้งแต่ตุลาคม 2020 รีโพสิทอรีใหม่ทั้งหมดบน GitHub ถูกสร้างขึ้นด้วยสาขา main GitLab และ Bitbucket ได้นำการสนับสนุน main เป็นชื่อเริ่มต้นมาใช้ด้วย Git 2.28 (กรกฎาคม 2020) เพิ่มตัวเลือก init.defaultBranch สำหรับกำหนดค่าชื่อสาขาเริ่มต้น

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

ในการเปลี่ยนชื่อสาขาในรีโพสิทอรีที่มีอยู่ ให้รัน:

# เปลี่ยนชื่อ master เป็น main ในเครื่อง
git branch -m master main

# อัปเดตรีโพสิทอรีระยะไกล
git push -u origin main

# ลบ master เก่าบนเซิร์ฟเวอร์
git push origin --delete master

# อัปเดต HEAD บนเซิร์ฟเวอร์
# (ผ่านอินเทอร์เฟซเว็บ GitHub: Settings → Branches → Default branch)

บทบาทของ main ใน Git Flow และ GitHub Flow

Git Flow และ GitHub Flow กำหนดบทบาทของสาขา main แตกต่างกัน การเลือกแบบจำลองขึ้นอยู่กับขนาดทีม ความถี่ในการเผยแพร่ และข้อกำหนดด้านความเสถียรของโค้ด

สำหรับการพัฒนาแอปมือถือ Git Flow เป็นมาตรฐาน เนื่องจากการเผยแพร่แอปใน App Store และ Google Play มีรอบการเผยแพร่ที่แน่นอน GitHub Flow เหมาะกับโปรเจกต์เว็บที่สามารถปรับใช้ได้หลายครั้งต่อวัน

GitHub Flow — แนวทางที่เรียบง่าย

ใน GitHub Flow ไม่มีสาขา develop สาขา feature ทั้งหมดถูกสร้างขึ้นโดยตรงจาก main และเมื่อเสร็จสิ้นจะถูกรวมกลับผ่าน Pull Request การรวมแต่ละครั้งใน main จะกระตุ้นการปรับใช้ในการผลิตโดยอัตโนมัติ แบบจำลองนี้ต้องการการทดสอบอัตโนมัติระดับสูงและวินัยของทีม

ใน GitHub Flow ไม่มีสาขา develop สาขา feature ทั้งหมดถูกสร้างขึ้นโดยตรงจาก main และเมื่อเสร็จสิ้นจะถูกรวมกลับผ่าน Pull Request การรวมแต่ละครั้งใน main จะกระตุ้นการปรับใช้ในการผลิตโดยอัตโนมัติ แบบจำลองนี้ต้องการการทดสอบอัตโนมัติระดับสูงและวินัยของทีม

การป้องกันสาขา main

การป้องกันสาขา สำหรับ main เป็นการตั้งค่าที่จำเป็นในโปรเจกต์เชิงพาณิชย์ใดๆ หากไม่มีมัน การ push โดยไม่ได้ตั้งใจอาจส่งโค้ดที่ยังไม่เสร็จไปยังการผลิตหรือทำลายแอปพลิเคชันที่ทำงานอยู่สำหรับผู้ใช้ทั้งหมด

• Require pull request — การ push โดยตรงไปยัง main ถูกห้าม การเปลี่ยนแปลงทั้งหมดผ่าน PR พร้อมการตรวจสอบ
• Require approvals — อย่างน้อย 2 การอนุมัติสำหรับการรวมใน main (ในกรณีที่ผู้ตรวจสอบพลาดบางสิ่ง)
• Require status checks — การตรวจสอบ CI/CD ทั้งหมดต้องผ่านก่อนการรวม
• Require up-to-date — PR ต้องขึ้นอยู่กับ commit main ล่าสุด
• Include administrators — การป้องกันใช้กับเจ้าของรีโพสิทอรีด้วย
• Require signed commits — commit ทั้งหมดใน main ต้องลงนามด้วยคีย์ GPG

การกำหนดค่า กฎทั้งหกข้อ เป็นมาตรฐานสำหรับโปรเจกต์มือถือที่มีผู้ใช้ 10,000+ คน สำหรับโปรเจกต์ขนาดเล็ก กฎสามข้อแรกก็เพียงพอ

การเปรียบเทียบระดับการป้องกันสำหรับโปรเจกต์ประเภทต่างๆ

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

การเผยแพร่และแท็กใน main

การแท็ก คือการปฏิบัติในการสร้างการอ้างอิงที่มีชื่อไปยัง commit เฉพาะใน main แต่ละแท็กสอดคล้องกับเวอร์ชันของแอปพลิเคชันที่เผยแพร่สู่การผลิต ซึ่งช่วยให้สลับไปยังเวอร์ชันก่อนหน้าใดๆ ได้อย่างรวดเร็วสำหรับการดีบักหรือแก้ไข

มาตรฐานการตั้งชื่อแท็กในการพัฒนาแอปมือถือคือ SemVer (การกำหนดเวอร์ชันเชิงความหมาย): v1.2.3 โดยที่หมายเลขแรกคือเวอร์ชันหลัก (การเปลี่ยนแปลงที่ทำลายความเข้ากันได้) หมายเลขที่สองคือเวอร์ชันรอง (ฟีเจอร์ใหม่) และหมายเลขที่สามคือแพตช์ (การแก้ไข)

แท็กถูกสร้างขึ้นหลังจากรวมสาขา release ใน main จากนั้น commit นี้จะถูกสร้างใน CI/CD ลงนาม และส่งไปยังร้านค้าแอป หากพบข้อผิดพลาดในแท็ก จะมีการสร้างสาขา hotfix จากแท็กนั้น

# สร้างแท็กเผยแพร่แบบมีคำอธิบาย
git tag -a v2.4.1 -m "Release version 2.4.1"

# ส่งแท็กไปยังเซิร์ฟเวอร์
git push origin v2.4.1

# ดูแท็กทั้งหมดในรีโพสิทอรี
git tag -l "v2.*"

# สร้างสาขา hotfix จากแท็กเฉพาะ
git checkout -b hotfix/crash-fix v2.4.1

ลำดับชั้นสาขา Git Flow

การเข้าใจลำดับชั้นสาขาใน Git Flow เป็นพื้นฐานสำหรับการจัดระเบียบการพัฒนาร่วมกันอย่างถูกต้อง สาขาแต่ละประเภทมีแหล่งที่มา วัตถุประสงค์ และกฎการรวมของตนเอง

• Main (ระดับ 1) — สาขาราก มีเฉพาะเวอร์ชันเผยแพร่ ถูกสร้างขึ้นเมื่อเริ่มต้นรีโพสิทอรี
• Develop (ระดับ 2) — ถูกสร้างจาก main เมื่อเริ่มโปรเจกต์ มีโค้ดรวมของคุณสมบัติทั้งหมด
• Feature (ระดับ 3) — ถูกสร้างจาก develop การพัฒนาแยกของคุณสมบัติแต่ละอย่าง
• Release (ระดับ 2) — ถูกสร้างจาก develop การเตรียมการเผยแพร่เฉพาะสำหรับการเปิดตัว
• Hotfix (ระดับ 2) — ถูกสร้างจาก main การแก้ไขข้อผิดพลาดร้ายแรงในการผลิตอย่างเร่งด่วน

กฎสำคัญ: feature ไม่ควรรวมโดยตรงใน main feature → develop → release → main คือห่วงโซ่การรวมที่ถูกต้อง การละเมิดกฎนี้ทำให้โมเดล Git Flow ทั้งหมดไร้ความหมาย

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

พิจารณาสถานการณ์: ทีมงานเตรียมการเผยแพร่ v2.5.0 เสร็จสมบูรณ์ สาขา release ได้รับการตรวจสอบและพร้อมที่จะรวมใน main หลังจากการรวม แท็กจะถูกสร้างขึ้นและเผยแพร่

# สลับไปยัง main และอัปเดต
git checkout main
git pull origin main

# รวมสาขา release ที่ตรวจสอบแล้ว
git merge --no-ff release/2.5.0

# สร้างแท็กเผยแพร่
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# ส่ง main และแท็กไปยังเซิร์ฟเวอร์
git push origin main --tags

แฟล็ก --no-ff (ไม่ใช้ fast-forward) รับประกันการสร้าง commit การรวม แม้ว่าการรวมสามารถทำได้โดยการเลื่อนพอยน์เตอร์เท่านั้น สิ่งนี้รักษาข้อมูลว่าการเปลี่ยนแปลงมาจากสาขา release ซึ่งทำให้การวิเคราะห์ประวัติง่ายขึ้น

การทำงานกับ hotfix ผ่าน main

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

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

# สร้างสาขา hotfix จาก main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# แก้ไขและ commit
git add src/fix/
git commit -m "Fix crash on login screen"

# รวม hotfix กลับไปยัง main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# รวม hotfix ใน develop ด้วย
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# ลบสาขา hotfix
git branch -d hotfix/2.5.1-crash-fix