Skip to main content
Back to articles

GitHub ย้าย Branch Protection ทั้ง Repo เป็น Rulesets ได้ครั้งเดียว พร้อมหน้าตรวจทานกฎ

GitHub เพิ่ม Bulk Import สำหรับแปลง Branch Protection เป็น Rulesets เลือกสถานะบังคับใช้และตรวจกรณีกฎซ้อนก่อนย้ายจริง

GitHub ย้าย Branch Protection ทั้ง Repo เป็น Rulesets ได้ครั้งเดียว พร้อมหน้าตรวจทานกฎ

GitHub ประกาศเมื่อวันที่ 20 ตุลาคม 2026 ว่าสามารถแปลง branch protection rules ทั้งหมดของ repository เป็น rulesets ในครั้งเดียวได้แล้ว ก่อนหน้านี้มีทางแปลงกฎทีละรายการ ความเปลี่ยนแปลงรอบนี้ช่วยทีมที่มีหลาย branch และหลายกฎลดงานย้ายด้วยมือ จุดสำคัญคือหน้าตรวจทานก่อนสร้าง rulesets เพราะกฎ branch protection หนึ่งข้ออาจต้องแตกเป็น rulesets มากกว่าหนึ่งรายการเพื่อคงพฤติกรรมเดิม

ทำไมต้องสนใจการย้ายกฎ

Branch protection ใช้กำหนดเงื่อนไขก่อน merge เช่นต้องผ่าน status checks ต้องมี review หรือจำกัดการ push ในขณะที่ rulesets เป็นกลไกที่จัดการกฎหลายชั้นและเลือกขอบเขตด้วย pattern ได้ รวมถึงการกำหนดระดับองค์กรหรือ enterprise ในสถานการณ์ที่ทีมมี repository เติบโตมาหลายปี กฎเดิมอาจถูกสร้างคนละช่วงเวลา มีข้อยกเว้นหลายแบบ และบางกฎครอบ branch ที่ซ้อนกัน หากย้ายโดยอ่านชื่อกฎอย่างเดียว อาจเปลี่ยนผลบังคับใช้จริงโดยไม่ตั้งใจ

ฟีเจอร์ใหม่เปิดทางให้เข้า Settings → Rulesets ของ repository แล้วเลือก Import branch protection rules ในหน้าทบทวน GitHub จะแสดง rulesets ที่จะสร้าง แสดงกฎเดิมที่ถูก ruleset อื่นครอบอยู่แล้ว และแจ้งกรณีที่หนึ่ง branch protection rule กลายเป็นหลาย rulesets ผู้ดูแลเลือก enforcement เป็น Active, Evaluate หรือ Disabled และเลือกเฉพาะ rulesets ที่จะสร้างได้ หลังสร้างจึงตัดสินใจว่าจะเก็บหรือลบ branch protection เดิม

วิธีใช้ในทีมที่มี CI จริง

ก่อนกด import ให้บันทึกสภาพปัจจุบันของกฎและระบุ branch สำคัญ เช่น main, release branch และ branch ชั่วคราวที่ workflow สร้างเอง จด required checks ชื่อจริงจาก CI, จำนวน review, สิทธิ์ bypass และข้อห้าม force push แล้วเลือก repository ที่มีความเสี่ยงต่ำเป็นชุดทดลอง หากย้ายทุก repository พร้อมกันและพบ pipeline ติดขัด จะยากที่จะรู้ว่ากฎใดทำให้เกิดปัญหา

ในหน้า Review import ให้เทียบผลลัพธ์กับรายการที่จดไว้ โดยเฉพาะกฎซ้อนกันและกรณีที่มี ruleset เดิมอยู่แล้ว สถานะ Evaluate เหมาะกับช่วงสังเกตผลก่อนบังคับจริง ส่วน Disabled ช่วยเตรียมกฎแต่ยังไม่บังคับ อย่างไรก็ตามการเลือกสถานะต้องสอดคล้องกับนโยบาย release ของทีม อย่าคิดว่า ruleset ที่สร้างแล้วทำงานเหมือนกฎเดิมทันทีโดยไม่ดู enforcement หลัง import ให้ทดลอง pull request ใหม่จาก contributor ปกติ บัญชี automation และผู้มีสิทธิ์ bypass ตรวจทั้งกรณี checks ผ่านและไม่ผ่าน รวมถึงการพยายาม push โดยตรงไป branch ที่ต้องป้องกัน

GitHub ให้เลือกเก็บหรือลบ branch protection เดิมหลังสร้าง rulesets ช่วงแรกการเก็บไว้ช่วยตรวจเทียบ แต่ต้องระวังว่ากฎเก่าและใหม่อาจบังคับพร้อมกันจนเกิดเงื่อนไขซ้ำหรือเข้มกว่าที่คาด ก่อนลบควรบันทึกผลทดสอบและวิธีย้อนกลับให้ชัด รวมถึงเวลาที่จะตรวจ log หลังเปลี่ยน งานย้าย policy ควรทำในช่วงที่ทีมพร้อมแก้ workflow หากพบผลต่าง ไม่ใช่ก่อน deploy สำคัญไม่กี่นาที

Rulesets ช่วยอะไรต่อจากนี้

ตามประกาศ GitHub rulesets เลือกหลาย branch ด้วย pattern ได้ วางกฎหลายชั้นเพื่อแยกนโยบายหลักกับข้อยกเว้นได้ และกำหนดระดับ organization หรือ enterprise ได้ นอกจากนี้ยังมีสิทธิ์ bypass ที่ละเอียดสำหรับผู้ใช้ ทีม และแอป ประโยชน์ไม่ได้อยู่แค่จำนวนคลิกที่ลดลง แต่ทำให้องค์กรวางนโยบายร่วมและตรวจสอบได้ว่า repository ต่าง ๆ ใช้หลักเดียวกันหรือไม่ อย่างไรก็ดีการย้ายเป็น rulesets ไม่ได้ทำให้ policy ที่ออกแบบผิดกลายเป็นถูก ทีมยังต้องทบทวนว่า checks ใดจำเป็นจริง และข้อยกเว้นเปิดกว้างเกินหรือไม่

ฟีเจอร์ import นี้พร้อมใช้ใน repository ที่รองรับ rulesets อยู่แล้ว หากไม่เห็นเมนูใน repository ที่ดูแล ให้ตรวจสิทธิ์จัดการ repository และการรองรับ rulesets ของแผนที่ใช้อยู่จากเอกสาร GitHub ก่อน อย่าสร้างกฎใหม่ทับแบบเดาสุ่ม ข่าวนี้จึงเหมาะกับทีม platform และผู้ดูแล repository ที่กำลังย้ายจาก branch protection เดิม โดยเริ่มจากการทบทวนพฤติกรรมจริงของ CI แล้วค่อยใช้เครื่องมือ bulk import เร่งขั้นตอนที่เหลือ

อ่านประกาศต้นทางวันที่ 20 ตุลาคม 2026: GitHub Changelog