GitHub stacked PR: diff เล็กไม่ได้แปลว่าปล่อยแยกได้

แบ่งงานใหญ่เป็นสาม PR ทำให้อ่านง่ายขึ้น แต่ PR บนที่พึ่งพา PR ล่างไม่ได้ปล่อยแยกได้โดยอัตโนมัติ

ประกาศวันที่ 6 ตุลาคม

GitHub ประกาศ GA เมื่อ 6 ตุลาคม 2026 สามารถ review PR เล็กแยกกันและ merge ร่วมกันได้ ใช้ได้ในทุกแผนของ github.com

stack เข้า merge queue เป็น merge group เดียว แต่ merge commit สร้าง commit ต่อ PR หน่วยทดสอบจึงไม่เหมือนหน่วยประวัติ

เขียนขอบเขต review

สมมติ A เพิ่มฟังก์ชัน B เรียกผ่าน API และ C ทำ UI ระบุ dependences และ base ที่ใช้เทียบ นี่เป็นข้อเสนอขั้นตอน ไม่ใช่การรับประกันอัตโนมัติของผลิตภัณฑ์

อ่าน B อย่างเดียวอาจพลาดการตรวจสิทธิ์ที่ขาดใน A แยก review diff กับตรวจ A+B+C และกำหนดผู้รับผิดชอบการรวม

อ่าน approval หลัง rebase

GitHub คง approval เมื่อ rebase stack ที่ไม่มีการเปลี่ยนอื่นหลัง base ขยับ แม้ตั้งให้ล้าง approval เก่า approval กับผลการรวมปัจจุบันจึงเป็นหลักฐานคนละอย่าง

บันทึก SHA ก่อนและหลังกับ merge group ที่ทดสอบ ตรวจว่าเทสรันใหม่และ log ครอบคลุมชุดใด เครื่องหมายเขียวอย่างเดียวไม่พอ

แยก merge กับ deployment

หากฟังก์ชันกับ API ต้องปล่อยพร้อมกัน ให้ระบุในแผน commit ต่อ PR ไม่รับประกันว่า rollback เดี่ยวจะไม่ทำให้ผู้เรียกที่เหลือเสีย

การแก้บั๊กอิสระไม่จำเป็นต้องเป็น stack การรวมอาจทำให้ทุกงานรอเทสเดียวที่ล่าช้า ให้ประเมินต้นทุนการดูแล

GA กับฟังก์ชันที่ใช้ได้จริง

GitHub ระบุว่า auto-merge จะทยอยมาในไม่กี่สัปดาห์ ตรวจปุ่มใน repository จริงก่อนสมมติว่าทุกบัญชีมีเหมือนกันวันนี้

feedback จาก preview ช่วยปรับการนำทางและอัตโนมัติ เป็นสัญญาณความสนใจ ไม่ใช่การรับประกันผลิตภาพ วัดเวลารอ review และความล้มเหลวเอง

เริ่ม stack เล็ก

เลือกสอง PR ที่พึ่งพากันชัดเจน เช่นฟังก์ชันกับผู้เรียก ระบุ base dependences และคำสั่งเทส ตกลงผู้รับผิดชอบกับขอบเขต rollback

เทียบเวลาที่ประหยัดกับข้อผิดพลาดใหม่ หากดูแลแพงกว่าให้กลับไป PR ปกติ ความชัดเจนในการ review และปล่อยงานสำคัญกว่าจำนวน diff

แหล่งข้อมูลทางการ

GitHub Changelog

ประกาศ 6 ตุลาคม ตรวจเมื่อ 8 ตุลาคม 2026 ตรวจ rules และฟังก์ชันก่อนใช้