GitHub ได้ย้าย stacked pull requests เข้าสู่ช่วง public preview ซึ่งช่วยให้นักพัฒนาสามารถแบ่งการเปลี่ยนแปลงขนาดใหญ่ให้กลายเป็นชุดของ PR ที่มีความเกี่ยวข้องกัน (dependent PRs) เพื่อให้สามารถรีวิวและ merge แยกกันได้อย่างอิสระ
ทำไมฟีเจอร์นี้ถึงสำคัญ
โดยปกติแล้ว PR ขนาดใหญ่เพียงอันเดียว (monolithic PR) มักจะลากยาวจนกลายเป็นการรีวิวที่กินเวลาเป็นเดือน ซึ่งทำให้ผู้รีวิวต้องเสียเวลาไล่ดูโค้ดที่ไม่เกี่ยวข้องจำนวนมาก และเมื่อ base branch มีการเปลี่ยนแปลง การเปลี่ยนแปลงขนาดใหญ่เหล่านั้นก็มักจะเกิด merge conflicts ที่ทำให้การปล่อย release ต้องหยุดชะงัก Stacked PRs ช่วยแก้ปัญหาทั้งสองอย่างนี้โดยการเปลี่ยน diff ขนาดใหญ่หนึ่งอัน ให้กลายเป็นชุดของ diff ขนาดเล็กที่เน้นเฉพาะจุด ซึ่งแต่ละอันจะต่อยอดจากอันก่อนหน้า
วิธีการทำงาน
สร้าง PR แรกโดยอ้างอิงกับ main branch จากนั้นให้ PR ถัดไปอ้างอิง (base) จากอันแรก อันที่สามอ้างอิงจากอันที่สอง เป็นเช่นนี้ไปเรื่อยๆ GitHub จะติดตามความสัมพันธ์เหล่านี้โดยอัตโนมัติ: หากคุณแก้ไข (amend) base PR, PR ที่เกี่ยวข้องกันจะได้รับการอัปเดตเพื่อให้สะท้อนถึงสถานะใหม่ ผู้รีวิวสามารถอนุมัติทั้ง stack ได้ด้วยการคลิกเพียงครั้งเดียว หรือจะเลือกอนุมัติทีละ layer ก็ได้
- การรีวิวจะอยู่ในขอบเขตที่แคบลง ทำให้ได้รับ feedback เร็วขึ้น
- ปัญหา conflict จะลดลง เพราะแต่ละ PR จะแตะเฉพาะโค้ดที่เพิ่มเข้ามาใน layer ของตัวเองเท่านั้น
- UI จะแสดงลำดับชั้นของ stack และ GitHub CLI ก็มีคำสั่งบรรทัดเดียว (one-liner) เพื่อสร้างชุด stacked PRs ได้ทันที
gh pr create --title Feature A --base main
gh pr create --title Feature B --base feature-a
gh pr create --title Feature C --base feature-b
ตัวอย่างคำสั่ง command line นี้จะสร้าง PR ที่เชื่อมโยงกันสามอัน โดยแต่ละอันจะขึ้นอยู่กับอันก่อนหน้า คุณสามารถใช้งานเวิร์กโฟลว์แบบเดียวกันนี้ผ่านอินเทอร์เฟซบนเว็บ ซึ่งคุณสามารถจัดลำดับใหม่หรือลบ PR ออกจาก stack ได้โดยไม่กระทบกับอันอื่นๆ
ใครจะได้รับประโยชน์จากฟีเจอร์นี้
ทีมพัฒนาฟีเจอร์ขนาดใหญ่และผู้ดูแลโปรเจกต์ open-source สามารถส่งมอบงานแบบค่อยเป็นค่อยไป (incremental work) ได้โดยไม่ทำให้ผู้รีวิวต้องเผชิญกับการเปลี่ยนแปลงโค้ดที่ไม่เกี่ยวข้อง ส่วนผู้จัดการการปล่อย release (Release managers) ก็จะเห็นภาพที่ชัดเจนขึ้นว่าส่วนไหนพร้อมสำหรับการปล่อยใช้งาน เนื่องจากแต่ละ layer ของ stack สามารถถูก merge ตามกำหนดการของตัวเองได้
ข้อควรระวังที่ต้องพิจารณา
ฟีเจอร์นี้ยังอยู่ในช่วง preview ดังนั้นอาจมีการเปลี่ยนแปลงก่อนที่จะมีการปล่อยตัวเต็ม ทีมต่างๆ จำเป็นต้องปรับเปลี่ยนนิสัยใหม่ๆ ในเรื่องการจัดการ branching และอาจพบกรณีที่ซับซ้อน (edge cases) เมื่อต้องทำการ rebase stack ที่ถูก merge ไปเพียงบางส่วนแล้ว นอกจากนี้เอกสารประกอบยังอยู่ในช่วงพัฒนา ดังนั้นผู้ใช้งานกลุ่มแรกๆ อาจต้องใช้เวลาเพิ่มเติมในการเรียนรู้การใช้งาน UI
สิ่งที่ควรติดตามต่อไป
GitHub มีแนวโน้มที่จะเพิ่มการทำงานร่วมกับ code-owners และเครื่องมืออัตโนมัติ (automation tools) ให้แน่นแฟ้นยิ่งขึ้น และอาจมีการแสดงตัวชี้วัด (metrics) เกี่ยวกับการลดปัญหา conflict โปรดติดตามหน้าประกาศ preview เพื่ออัปเดตเกี่ยวกับช่วงเวลาการเปิดใช้งานทั่วไป (GA - general availability)
สรุปประเด็นสำคัญ: Stacked pull requests ช่วยให้นักพัฒนามีวิธีที่ใช้งานได้จริงในการจัดการกับการเปลี่ยนแปลงขนาดใหญ่ โดยเปลี่ยนจาก PR อันเดียวที่เต็มไปด้วยปัญหา conflict ให้กลายเป็นลำดับขั้นตอนที่จัดการได้ง่ายและเอื้อต่อการรีวิว หากเวิร์กโฟลว์ของคุณต้องเผชิญกับการรีวิวที่ยาวนานและปัญหาปวดหัวจากการ merge การทดลองใช้เวอร์ชัน preview นี้ถือว่าคุ้มค่าที่จะลอง
