ลอง cherry-pick GitHub PR กันดู

• เริ่มใช้ mono-repository ภายในองค์กรมาได้ 4 เดือนแล้ว
• และได้นำ trunk-based development ซึ่งเป็นคีย์เวิร์ดที่มักมาคู่กับ mono-repository มาใช้ด้วย
• ตามกลยุทธ์ trunk-based development จึงใช้ flow ที่ commit ลงบนสาขา main แล้ว cherry-pick ไปยังสาขา release
• อ้างอิงเนื้อหาจาก บล็อกเทคโนโลยีของ LinkedIn แล้วตั้งค่า GitHub Action ขึ้นมา แต่ยังไม่สามารถแก้ CONFLICT ให้อัตโนมัติได้ หากเกิด CONFLICT ผู้ใช้ยังต้องรันคำสั่ง git cherry-pick ด้วยตัวเองบน local
• จึงได้ลองทำปลั๊กอิน gh สำหรับช่วยคำสั่ง cherry-pick นี้ขึ้นมาเอง

วิธีใช้งาน

gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]  

• ใช้ตัวเลือก -merge เพื่อเลือกว่าจะ cherry-pick merge commit ของ PR หรือจะ cherry-pick commit ต้นฉบับของ PR
  • หากไม่ระบุ หรือใช้ตัวเลือก -merge=auto ระบบจะ inspect กลยุทธ์การ merge ของ PR โดยอัตโนมัติแล้วนำไปใช้
• ใช้ตัวเลือก -push เพื่อให้รองรับการ push ไปยัง remote อัตโนมัติเมื่อ cherry-pick สำเร็จ

ความเห็นหลังใช้งาน

• ได้พัฒนาโปรแกรมที่ต้องโต้ตอบกับ process ภายนอกและ state ต่าง ๆ อย่างต่อเนื่อง จึงสร้าง test repository แยกขึ้นมาเพื่อทำ Test Dataset
  • ประสบการณ์ที่เคยมีส่วนร่วมกับโปรเจกต์ libgit2 และ refined-github ในอดีตช่วยได้มาก
• ได้ศึกษาเรื่องต่าง ๆ เพื่อทำให้ประสบการณ์ใช้งาน CLI ดีขึ้น
  • การศึกษาที่ทำไว้เพื่อจะลองสร้าง docker-cli เองคนเดียวช่วยได้มาก
• การทำโปรแกรม CLI ใช้แรงกว่าที่คิดมาก
  • การจัดการค่า state จำนวนมากในรูปแบบ pipeline
  • การออกแบบ input interface ที่เข้าใจง่ายสำหรับผู้ใช้
  • การทำ input validation ให้เร็วที่สุดเท่าที่ทำได้
  • การกู้คืนระบบของผู้ใช้กลับสู่สภาพเดิม เป็นต้น
  • เดิมคิดว่าน่าจะทำเสร็จได้ภายในประมาณ 1 วัน แต่สุดท้ายใช้เวลาราว 5 วัน (แม้ว่าจะมีการพัฒนาควบคู่กันไปเพื่อปรับปรุง GitHub Actions Workflow ด้วย แต่ก็ยังใช้เวลามากกว่าที่คาดไว้มาก)

[qncnxnlrla]

สวัสดีครับ~ ถ้าจำเป็นต้อง revert คอมมิตที่ merge เข้า main(trunk) branch ไปแล้ว ปกติคุณจัดการกันอย่างไรบ้างครับ?

• ถ้า revert บน main branch แล้วจะต้อง cherry-pick ไปที่ release branch ด้วยไหม?
• หรือจะไม่ใช้ revert แล้วเพิ่มคอมมิตแก้ไขเข้าไปแทน?

ถ้ามีคอมมิตสะสมอยู่เยอะจนเกิด conflict แล้วทำให้ cherry-pick ยาก น่าจะมีกรณีแบบนี้อยู่เหมือนกัน เลยอยากทราบว่ามีใครเคยจัดการเคสแบบนี้บ้างไหมครับ!

[a1eng0]

สวัสดีครับ~ ขอบคุณที่คอมเมนต์เข้ามานะครับ!

ถ้าจำเป็นต้อง revert คอมมิตที่ถูก merge เข้าไปในสาขา main(trunk) แล้ว ปกติจัดการอย่างไรครับ?

เราจะระบุ cherry-pick ไว้ใน PR ที่ใช้ revert บนสาขา main ครับ เพราะประวัติการ cherry-pick จะยังคงอยู่ครบในลิงก์ PR ต้นฉบับทั้งหมด จึงไม่ได้มีความยากในการติดตามเป็นพิเศษ และก็ไม่ได้มีการทำ mechanical check แยกต่างหากครับ ฮ่าๆ

ถ้ามีคอมมิตสะสมเยอะจนเกิด conflict แล้วทำให้ cherry-pick ได้ยาก

อย่างแรกเลย ถ้าทำ trunk-based development แต่ละ PR จะมีขนาดเล็ก จึงไม่ได้เกิด conflict บ่อยนักครับ แต่ถ้าเกิด conflict ขึ้นมาจริง ๆ ก็ต้องเขียนโค้ดแก้ด้วยมือนะครับ เราออก release กันบ่อยมาก ๆ เพื่อเลิกซัพพอร์ตเวอร์ชันเก่าเกินไปได้เร็ว และหลีกเลี่ยงไม่ให้สภาพโค้ดเปลี่ยนไปมากจนเกินไปครับ!

[lamanus]

ดูเป็นแนวทางที่ผมยังไม่ค่อยเข้าใจนักว่าทำไมถึงจำเป็น...

[a1eng0]

ถ้าลองอ่านเนื้อหาที่แนะนำไว้ใน release-from-trunk ก็น่าจะช่วยให้เข้าใจได้มากขึ้นครับ 555