GitHub เปิดใช้ Stacked Pull Requests ทุกแผน แตกงานใหญ่เป็น PR ย่อยที่รีวิวแยกได้
GitHub ให้ Stacked Pull Requests ใช้งานทั่วไปเมื่อ 6 ต.ค. 2026 ทุกแผนบน github.com แตกงานใหญ่เป็น PR ย่อยที่รีวิวแยกกันได้ ส่วน GitHub Enterprise Server จะตามมา
โดย กองบรรณาธิการ THAI DATA อ่าน 4 นาที
สรุปประเด็นสำคัญ
- GitHub ประกาศเมื่อ 6 ตุลาคม 2026 ให้ Stacked Pull Requests พร้อมใช้งานทั่วไป (GA) บน github.com ทุกแผน หลังเปิดทดลองแบบ public preview ตั้งแต่ 30 กรกฎาคม 2026
- GitHub ระบุว่า repository ที่ใช้ stack มีโค้ดที่ถูก merge เพิ่มขึ้น 9% เมื่อเทียบกับกลุ่มเดียวกัน และ repository ระดับ top 1% กว่า สองในสาม ใช้ฟีเจอร์นี้แล้ว โดยเวลาถึง merge ดีขึ้น 5%
- รุ่น GA ทำให้ Rebase stack ไม่ล้างการอนุมัติของโค้ดที่ไม่ได้เปลี่ยน สร้าง commit ที่เซ็นแล้วแทนของเดิม และส่งทั้ง stack เข้า merge queue เป็น merge group เดียว ส่วน auto-merge ทยอยเปิดภายในไม่กี่สัปดาห์
- ทุก PR ใน stack ต้องผ่านกฎ branch protection และ CI ชุดเดียวกับ branch ปลายทาง เช่น
mainทำให้ workflow ของ GitHub Actions รัน 1 ครั้งต่อ PR ทีมจึงควรใช้ข้อมูลstackในเงื่อนไขเพื่อคุมค่า CI - Stack ต้องอยู่ใน repository เดียวกัน ใช้ข้าม fork ไม่ได้ และไม่รองรับ GitHub Desktop ส่วน GitHub Enterprise Server จะได้ฟีเจอร์นี้ในรุ่นที่จะออกต่อไป
GitHub ประกาศเมื่อวันที่ 6 ตุลาคม 2026 ว่า Stacked Pull Requests พร้อมใช้งานทั่วไปบน github.com ทุกแผนแล้ว ฟีเจอร์นี้ให้นักพัฒนาแตกงานชิ้นใหญ่ออกเป็น pull request (PR) ชิ้นเล็กที่ต่อกันเป็นชั้น รีวิวแยกกันได้ แล้วสั่ง merge ทั้งชุดได้ในครั้งเดียว
รุ่นนี้ออกหลังเปิดทดลองแบบ public preview มาตั้งแต่ 30 กรกฎาคม 2026 GitHub ระบุว่า repository ที่ใช้ stack มีโค้ดที่ถูก merge เพิ่มขึ้น 9% เมื่อเทียบกับกลุ่มเดียวกัน ส่วนองค์กรที่ใช้ GitHub Enterprise Server ต้องรอรุ่นถัดไป
Stacked Pull Requests ทำงานอย่างไร
เอกสารของ GitHub อธิบายว่า stack คือ PR ตั้งแต่ 2 รายการขึ้นไปใน repository เดียวกัน PR ล่างสุดชี้ไปที่ branch หลัก (trunk) ซึ่งมักเป็น main หรือ release branch ส่วน PR ชั้นถัดไปแต่ละรายการชี้ไปที่ branch ของชั้นด้านล่าง หลักคือของที่เป็นฐานอย่างชนิดข้อมูลกลางหรือ schema ของฐานข้อมูลอยู่ชั้นล่าง แล้วโค้ดที่พึ่งพามันอย่าง API และหน้าจออยู่ชั้นบน
แต่ละ PR แสดงเฉพาะส่วนต่างระหว่าง branch ของตัวเองกับชั้นด้านล่าง ผู้รีวิวจึงอ่าน diff สั้น ๆ ทีละชั้นได้พร้อมกันหลายคน และใช้แผนผัง stack ด้านบนของหน้า PR ดูว่าชั้นที่กำลังอ่านอยู่ตรงไหนของงานทั้งหมด
ที่ผ่านมา ทีมที่แตก PR เป็นชุดต้อง rebase หลาย branch ให้ตรงกันเอง และกฎ branch protection กับ CI มักทำงานเฉพาะ PR ล่างสุด เมื่อใช้ Stacked Pull Requests กติกาของ main เช่นการอนุมัติจาก CODEOWNERS และ CI ที่ตั้งไว้กับ PR ที่ชี้ไป main จะมีผลกับทุกชั้น รวมถึงชั้นกลางที่ไม่ได้ชี้ไป main โดยตรง
สิ่งที่เพิ่มเข้ามาใน Stacked Pull Requests รุ่น GA
GitHub สรุปการปรับปรุงที่มาพร้อมสถานะ GA ไว้ดังนี้
| เรื่อง | สิ่งที่เปลี่ยน |
|---|---|
| การอนุมัติ | Rebase stack หลัง main ขยับไปข้างหน้าไม่ล้างการอนุมัติของ stack ที่โค้ดไม่ได้เปลี่ยน แม้ repository จะตั้งให้ยกเลิกการอนุมัติที่ล้าสมัย |
| commit ที่เซ็นไว้ | GitHub สร้าง commit ใหม่ที่เซ็นแล้วตอน rebase โดยคงชื่อผู้เขียนเดิม |
| สิทธิ์ข้ามกฎ | ผู้ที่มีสิทธิ์ bypass กฎของ repository ใช้สิทธิ์นั้น merge PR ล่างสุดที่ยังไม่ merge ได้ |
| merge queue | ทั้ง stack เข้า merge queue เป็น merge group เดียว และวิธี merge commit จะสร้าง 1 merge commit ต่อ 1 PR |
| branch ฐานถูกลบ | GitHub ย้ายเป้าหมายของ stack ให้อัตโนมัติแทนการปิด PR ล่างสุด |
| auto-merge | ทยอยเปิดภายในไม่กี่สัปดาห์ เลือก PR เป็นกลุ่มแล้วให้ merge พร้อมกันเมื่อผ่านเงื่อนไขครบ |
ด้านการใช้งานประจำวัน ข้อมูล stack แสดงอยู่ที่ส่วนหัวของหน้า PR ตลอดเวลาและในหน้ารายการ PR ใช้ปุ่มลัด Shift+J และ Shift+K เลื่อนระหว่างชั้น timeline บันทึกเมื่อ PR ถูกเพิ่มหรือนำออกจาก stack และ webhook pull_request มี action ชื่อ stacked เมื่อ PR เข้าร่วม stack ส่วนขยาย gh stack ของ GitHub CLI รองรับ Git worktree แล้ว
ข้อจำกัดที่ต้องรู้คือทุก branch ใน stack ต้องอยู่ใน repository เดียวกัน ใช้กับ PR จาก fork ไม่ได้ และ GitHub Desktop ยังไม่รองรับ การ merge ต้องไล่จากชั้นล่างขึ้นบนเสมอ ถ้าสั่ง merge PR ชั้นบนสุด ชั้นด้านล่างทั้งหมดจะถูก merge ไปด้วย
ทำไม Stacked Pull Requests จึงสำคัญในยุคเอเจนต์เขียนโค้ด
ตัวเลขที่ GitHub เปิดเผยพร้อมประกาศชี้ว่าฟีเจอร์นี้ถูกใช้จริงในกลุ่ม repository ที่ทำงานหนาแน่น นอกจากตัวเลข 9% repository ระดับ top 1% กว่าสองในสามใช้ stack แล้ว และเวลาถึง merge ดีขึ้น 5%
เหตุผลเบื้องหลังเกี่ยวกับ AI โดยตรง เอกสารของ GitHub ระบุว่าเมื่อเอเจนต์สร้างโค้ดจำนวนมากในคราวเดียว stack ให้แต่ละงานมีที่ของตัวเอง คือ 1 PR ต่อ 1 งาน ต่อยอดจากชั้นก่อนหน้า ในประกาศช่วงทดลอง Andy Merryman ซีทีโอของ TED กล่าวว่า AI ทำให้นักพัฒนาทำงานได้มากขึ้นมาก แต่ก็สร้างคอขวดใหม่ เพราะ PR ใหญ่จนผู้รีวิวตามไม่ทัน
จุดที่ต่างจากการแตก PR เป็นชุดด้วยมือคือ stack เป็นความสามารถในตัวแพลตฟอร์ม GitHub ระบุว่าการรีวิว การตรวจสอบ และเงื่อนไขการ merge ที่ทีมตั้งไว้เดิมทำงานกับ stack ได้ทันที ทั้ง branch protection, merge queue และ GitHub Actions สำหรับประเด็นการคุมเอเจนต์เขียนโค้ดในฝั่งเครื่องนักพัฒนา อ่านเพิ่มได้ที่ข่าว Microsoft เปิดใช้ MXC คอนเทนเนอร์จำกัดสิทธิ์เอเจนต์ AI
ผลต่อองค์กรไทย
- ทีมที่ใช้ github.com เริ่มใช้ Stacked Pull Requests ได้ทันที โดยไม่ต้องรออัปเกรด เลือกโปรเจกต์ที่มี PR ใหญ่บ่อยหรือใช้เอเจนต์เขียนโค้ดมาก ทดลองแตกงานด้วย
gh extension install github/gh-stackแล้ววัดเวลารีวิวก่อนและหลัง - องค์กรที่ใช้ GitHub Enterprise Server ในศูนย์ข้อมูลของตัวเอง เช่น หน่วยงานที่ต้องเก็บซอร์สโค้ดไว้ภายใน ควรใส่ฟีเจอร์นี้ในแผนอัปเกรดรอบถัดไป เพราะ GitHub ยังไม่ระบุรุ่นที่จะได้รับ
- ทบทวนงบ CI ก่อนเปิดใช้วงกว้าง workflow ที่ชี้ไป
mainจะรันกับทุกชั้นของ stack ทีมควรใช้ค่าgithub.event.pull_request.stack.positionและstack.sizeให้งานหนัก เช่น integration test หรือ build image รันเฉพาะชั้นล่างสุดที่ยังไม่ merge หรือชั้นบนสุด โดยเฉพาะทีมที่จ่ายค่า runner ตามนาทีที่ใช้ - ตรวจนโยบายการอนุมัติและการเซ็น commit การ rebase ที่คงการอนุมัติไว้และการสร้าง commit ใหม่ที่เซ็นแล้วกระทบหลักฐานที่ผู้ตรวจสอบภายในใช้ ทีมที่ต้องผ่านการตรวจตามมาตรฐานควรบันทึกวิธีที่ stack ทำงานลงในเอกสารกระบวนการ
- ตกลงวิธีแบ่งชั้นร่วมกันในทีม เช่น schema และชนิดข้อมูลกลางอยู่ล่าง API อยู่กลาง หน้าจออยู่บน และกำหนดว่าใครรีวิวชั้นใด จะได้ประโยชน์จากการรีวิวคู่ขนานเต็มที่ ติดตามข่าวเครื่องมือนักพัฒนาเพิ่มเติมได้ที่หมวดซอฟต์แวร์
คำถามที่พบบ่อย
Stacked Pull Requests ของ GitHub คืออะไร?
Stacked Pull Requests คือชุดของ pull request ตั้งแต่ 2 รายการขึ้นไปใน repository เดียวกันที่ต่อกันเป็นชั้น PR ล่างสุดชี้ไปที่ branch หลัก เช่น main ส่วน PR ชั้นถัดไปชี้ไปที่ branch ของชั้นด้านล่าง ผู้รีวิวจึงเห็นเฉพาะส่วนที่เปลี่ยนในแต่ละชั้น และทีมสั่ง merge ทั้งชุดได้ในครั้งเดียว
Stacked Pull Requests ใช้ได้กับ GitHub แผนไหนบ้าง?
GitHub ระบุว่า Stacked Pull Requests ใช้ได้กับทุกแผนบน github.com ตั้งแต่สถานะ GA เมื่อ 6 ตุลาคม 2026 ส่วนองค์กรที่ติดตั้ง GitHub Enterprise Server ไว้เองต้องรอรุ่นที่จะออกต่อไป ซึ่ง GitHub ยังไม่ได้ระบุหมายเลขรุ่นหรือวันที่
ใช้ Stacked Pull Requests แล้วค่า GitHub Actions จะเพิ่มขึ้นไหม?
การใช้ Stacked Pull Requests อาจทำให้ค่า CI เพิ่มขึ้น เพราะเอกสารของ GitHub ระบุว่า workflow ที่ตั้งให้รันกับ pull request ที่ชี้ไป main จะรันกับทุก PR ใน stack ไม่ใช่เฉพาะชั้นล่างสุด stack ที่มีหลายชั้นจึงใช้ CI หลายเท่า ทีมลดได้ด้วยการอ่านค่า github.event.pull_request.stack แล้วรันงานหนักเฉพาะชั้นล่างสุดที่ยังไม่ merge หรือชั้นบนสุด
เริ่มใช้ stacked pull requests ได้อย่างไร?
สร้าง stack ได้ทั้งบนหน้าเว็บ github.com, GitHub Mobile และ GitHub CLI โดยติดตั้งส่วนขยายด้วยคำสั่ง gh extension install github/gh-stack จากนั้นเปิด PR แรกให้ชี้ไปที่ main แล้วเพิ่ม branch และ PR ใหม่ซ้อนด้านบน เอเจนต์เขียนโค้ดอย่าง GitHub Copilot ก็ใช้ผ่าน gh-stack skill ได้
แหล่งอ้างอิง
- Stacked pull requests generally available — GitHub Changelog
- Stacked pull requests are now in public preview — GitHub Changelog
- About stacked pull requests — GitHub Docs
- Optimizing CI for stacked pull requests — GitHub Docs
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ