นักพัฒนาซอฟต์แวร์ต้องดิ้นรนกับการรักษา patch แบบกำหนดเองข้ามเวอร์ชันต่างๆ ของซอฟต์แวร์บุคคลที่สามมาเป็นเวลานาน แม้ว่า Git จะเก่งในการพัฒนาที่เคลื่อนไปข้างหน้า แต่ก็มีข้อจำกัดเมื่อทีมงานต้องการรักษา patch ที่มีอายุยาวนานซึ่งต้องได้รับการอัปเดต ติดตาม และทำงานร่วมกันเป็นเดือนหรือปี เครื่องมือใหม่ที่เรียกว่า Lappverk มีเป้าหมายที่จะเชื่อมช่องว่างนี้โดยการรวม interface ที่คุ้นเคยของ Git เข้ากับ workflow แบบ patch-based
ปัญหาหลักของแนวทางแบบดั้งเดิม
ความท้าทายอยู่ที่ปรัชญาการออกแบบพื้นฐานของ Git Git ต้องการให้ประวัติเคลื่อนไปข้างหน้าผ่าน commit ใหม่ แต่ patch ต้องการการจัดการที่แตกต่างกัน patch ต้องการความสามารถในการถูกแก้ไข rebase ข้ามเวอร์ชัน upstream และรักษาเป็นหน่วยแยกต่างหากเป็นระยะเวลานาน การอภิปรายในชุมชนเผยให้เห็นว่านี่ไม่ใช่แค่ปัญหาเชิงทฤษฎี - มันส่งผลกระทบต่อ Linux distribution สภาพแวดล้อมขององค์กร และใครก็ตามที่รักษา soft fork ของโปรเจกต์ upstream
วิธีแก้ปัญหาแบบดั้งเดิมเช่นการรักษา Git branch แยกต่างหากผ่านการ rebase สร้างปัญหาใหญ่ในการทำงานร่วมกัน เมื่อสมาชิกในทีมหลายคนทำงานกับ patchset เดียวกัน การ rebase อย่างต่อเนื่องทำลายโมเดลการทำงานร่วมกันของ Git อย่างสิ้นเชิง แนวทางทางเลือกของการใช้ merge commit ทำให้ patch ต่างๆ พันกันอย่างรวดเร็ว ทำให้การติดตามหรือแก้ไขการเปลี่ยนแปลงแต่ละรายการเป็นไปไม่ได้
วิธีที่ Lappverk พยายามแก้ไขปัญหา
Lappverk ใช้แนวทางแบบผสมโดยการนำเข้า patchset เข้าสู่ Git เพื่อแก้ไข จากนั้นส่งออกกลับเป็นไฟล์ patch แบบดั้งเดิม workflow นี้ใช้ประโยชน์จากคำสั่ง format-patch และ am ที่มีอยู่ของ Git พร้อมเพิ่มแนวทางปฏิบัติเพื่อทำให้กระบวนการราบรื่นขึ้น เครื่องมือนี้ปรับ metadata ของ commit ให้เป็นมาตรฐานเพื่อให้แน่ใจว่าการส่งออกมีความสอดคล้องและติดตามขอบเขต upstream โดยอัตโนมัติ
ระบบนี้ช่วยให้ทีมงานทำงานกับคำสั่ง Git และเครื่องมือที่คุ้นเคยในขณะที่รักษา patch เป็นไฟล์ข้อความที่สามารถจัดเวอร์ชันได้ patch แต่ละตัวยังคงเป็นหน่วยแยกต่างหากที่สามารถแก้ไข จัดลำดับใหม่ หรือลบออกได้โดยไม่ส่งผลกระทบต่อตัวอื่นในชุด
คำสั่งเวิร์กโฟลว์พื้นฐานของ Lappverk
| คำสั่ง | วัตถุประสงค์ |
|---|---|
lappverk init project |
สร้างโปรเจกต์ใหม่และชุดแพตช์ |
lappverk checkout |
ตรวจสอบสถานะชุดแพตช์ปัจจุบัน |
lappverk export |
อัปเดตชุดแพตช์จากคอมมิตปัจจุบัน |
git format-patch |
คำสั่งสร้างแพตช์ในตัวของ Git |
git am |
คำสั่งนำเข้าแพตช์ในตัวของ Git |
การตอบรับจากชุมชนและแนวทางทางเลือก
ความคิดเห็นจากนักพัฒนาแสดงปฏิกิริยาที่หลากหลายต่อความจำเป็นของเครื่องมือนี้ บางคนโต้แย้งว่า workflow ของ Git ที่มีอยู่พร้อมการจัดการ branch อย่างระมัดระวังแก้ไขปัญหาเหล่านี้ได้อย่างเพียงพอแล้ว คนอื่นๆ ชี้ไปที่เครื่องมือที่มีอยู่แล้วเช่น Quilt ซึ่ง distribution ได้ใช้มาหลายปีเพื่อจัดการคอลเลกชัน patch แม้ว่า Quilt จะมาพร้อมกับเส้นโค้งการเรียนรู้และข้อจำกัดของตัวเอง
ความจริงก็คือมีคำแนะนำที่มีอยู่น้อยมากสำหรับการรักษา soft fork ที่ไม่ตั้งใจจะ upstream patch
นักพัฒนาหลายคนแบ่งปันวิธีแก้ปัญหาของตัวเอง ตั้งแต่ระบบซิงค์อัตโนมัติที่ใช้โดยโปรเจกต์เช่น Servo และ Firefox ไปจนถึง workflow การ rebase แบบง่ายๆ ด้วยชื่อ branch ที่มีวันที่ ความหลากหลายของแนวทางเน้นย้ำว่าแต่ละทีมได้พัฒนาวิธีแก้ปัญหาแบบกำหนดเองสำหรับปัญหาทั่วไปนี้
เครื่องมือจัดการ Patch ทางเลือก
- Quilt: เครื่องมือจัดการ patch แบบดั้งเดิมที่ใช้โดย Linux distributions
- git-spice: ทางเลือกแทน stgit สำหรับการจัดการ patch stack
- Jujutsu: ระบบควบคุมเวอร์ชันที่ปรับเปลี่ยนประวัติได้ง่ายกว่า
- Wine-staging: ตัวอย่างของการจัดการ patch ขนาดใหญ่ในทางปฏิบัติ
- Standard Git rebasing: วิธีการแบบ manual โดยใช้การจัดการ branch และ force pushes
การประยุกต์ใช้ในโลกจริงและกรณีการใช้งาน
เครื่องมือนี้ดูเหมือนจะมีค่ามากที่สุดสำหรับองค์กรที่รักษาการแก้ไขภายในของซอฟต์แวร์โอเพนซอร์ส ตัวอย่างรวมถึงการอัปเกรด dependency การ backport การแก้ไขบัก และฟีเจอร์แบบกำหนดเองที่ไม่เหมาะสมสำหรับการมีส่วนร่วม upstream Wine-staging และผู้ดูแลแพ็กเกจ Linux distribution ต่างๆ เผชิญกับความท้าทายที่คล้ายกันเมื่อจัดการ patch ข้ามเวอร์ชันซอฟต์แวร์
สภาพแวดล้อมขององค์กรมักต้องการ patch ที่เฉพาะเจาะจงเกินไปสำหรับการตั้งค่าของพวกเขาหรือมีการแก้ไขที่เป็นกรรมสิทธิ์ที่ไม่สามารถแบ่งปันต่อสาธารณะได้ สำหรับกรณีการใช้งานเหล่านี้ แนวทางของ Lappverk ในการจัดการ patch เป็น artifact ชั้นหนึ่งที่สามารถจัดเวอร์ชันได้นั้นสมเหตุสมผล
แม้ว่า Lappverk อาจไม่ปฏิวัติการพัฒนาซอฟต์แวร์ แต่มันแก้ไขจุดเจ็บปวดที่แท้จริงที่นักพัฒนาหลายคนพบเจอ การที่มันจะได้รับการยอมรับหรือไม่น่าจะขึ้นอยู่กับว่ามันบูรณาการกับ workflow ที่มีอยู่ได้ดีเพียงใดและทีมงานพบว่าประโยชน์ของมันมีค่ามากกว่าความซับซ้อนของการเรียนรู้เครื่องมืออีกตัวหนึ่งหรือไม่ สำหรับองค์กรที่กำลังดิ้นรนกับการจัดการ patch อยู่แล้ว มันเสนอทางเลือกที่มีโครงสร้างแทนวิธีแก้ปัญหาแบบชั่วคราว
อ้างอิง: Modifying Other People's Software