- เป้าหมายคือการสร้างเครื่องมือทำงานร่วมกันสำหรับ git ที่เรียบง่ายที่สุด
- ทำให้การรันเซิร์ฟเวอร์ git แบบโฮสต์เองง่ายพอๆ กับการรันเซิร์ฟเวอร์ SSH โดยไม่ต้องแลกกับเวลาและพลังงานของผู้ร่วมพัฒนาจากภายนอก
- ผสานเวิร์กโฟลว์ของ mailing list และ pull request เข้าด้วยกัน
- ต้องการสร้างเครื่องมือทำงานร่วมกันที่เรียบง่ายพอๆ กับการสร้างแพตช์ แต่ใช้งานสะดวกแบบ pull request
- ไม่ได้ต้องการสร้างคลังโค้ดอีกแห่งหนึ่ง แต่ต้องการสร้างโซลูชัน git แบบโฮสต์เองที่เรียบง่ายมากสำหรับการทำงานร่วมกับผู้มีส่วนร่วมจากภายนอก
สิ่งที่ต้องมี
- สิ่งที่เจ้าของโค้ดต้องมีเพื่อรันเซิร์ฟเวอร์ git:
- ไบนารี golang เพียงไฟล์เดียว
- สิ่งที่ผู้มีส่วนร่วมจากภายนอกต้องมี:
- คู่กุญแจ SSH
- ไคลเอนต์ SSH
ปัญหาในปัจจุบัน
- อีเมลนั้นยอดเยี่ยมในฐานะระบบกระจายสำหรับส่งและรับการเปลี่ยนแปลงต่อคลัง git (ชุดแพตช์) แต่การพาผู้ใช้ใหม่เข้าสู่ mailing list การตั้งค่าอีเมลไคลเอนต์ให้ถูกต้อง และแค่การส่งผลงานโค้ด ก็เพียงพอจะทำให้นักพัฒนาจำนวนมากถอดใจ
- การทำงานร่วมกันผ่านโปรโตคอลอีเมลทำให้ชุดความสามารถมีข้อจำกัด ตัวอย่างเช่น แก้ไขอีเมลไม่ได้ ทุกคนใช้ไคลเอนต์ต่างกัน และไคลเอนต์เหล่านี้ก็มีข้อจำกัดต่างกันเกี่ยวกับอีเมลข้อความล้วนและการดาวน์โหลดแพตช์
- pull request ของ Github ใช้งาน แก้ไข และจัดการได้ง่าย แต่ข้อเสียคือผู้ใช้ต้องอยู่ภายในเว็บไซต์ Github เพื่อทำ code review
- มันดีสำหรับการเปลี่ยนแปลงที่รวดเร็ว แต่เมื่อเริ่มอ่านโค้ดในเว็บเบราว์เซอร์ก็มีข้อเสียชัดเจนมากขึ้น จนถึงจุดหนึ่งการรีวิวโค้ดในสภาพแวดล้อมการพัฒนาแบบโลคัลหรือ IDE ย่อมสมเหตุสมผลกว่า
- แม้จะมีเครื่องมือและปลั๊กอินสำหรับรีวิว PR ภายใน IDE แต่การทำให้ใช้งานได้จริงต้องใช้ความพยายามอย่างมาก
- นอกจากนี้ โซลูชันแบบโฮสต์เองที่เลียนแบบ pull request ยังต้องใช้อินฟราสตรักเจอร์จำนวนมากในการดูแล ทั้งฐานข้อมูล เว็บไซต์ที่เชื่อมกับ git การดูแลโดยผู้ดูแลระบบ บริการต่างๆ
- อีกจุดเสียดทานใหญ่คือผู้ใช้ภายนอกต้องสร้างบัญชีและล็อกอินก่อนจึงจะส่งการเปลี่ยนแปลงโค้ดได้ สิ่งนี้เพิ่มความยุ่งยากอย่างมากทั้งกับผู้มีส่วนร่วมจากภายนอกและเจ้าของโค้ดที่ต้องจัดเตรียมอินฟราสตรักเจอร์
- บ่อยครั้งต้อง fork คลังภายในที่เก็บโค้ดก่อนจึงจะส่ง PR ได้ จากนั้นก็ไม่กลับมามีส่วนร่วมอีก แต่ยังคงมีคลังที่ fork ไว้ตลอดไป ซึ่งดูไม่สมเหตุสมผล
แนะนำ Patch Request (PR)
- ต้องการสร้าง "เซิร์ฟเวอร์" git แบบโฮสต์เองที่สามารถส่งและรับแพตช์ได้ โดยไม่ต้องยุ่งยากกับการตั้งค่าอีเมลหรือข้อจำกัดที่โปรโตคอลอีเมลบังคับไว้
- อีกทั้งยังต้องการให้เวิร์กโฟลว์หลักยึดรอบสภาพแวดล้อมการพัฒนาแบบโลคัล ขณะที่ Github สนับสนุนเวิร์กโฟลว์ด้วยการนำ IDE มาไว้ในเบราว์เซอร์ แต่ที่นี่ต้องการกลับแนวคิดนั้น โดยทำให้การรีวิวโค้ดในสภาพแวดล้อมการพัฒนาแบบโลคัลเป็นพลเมืองชั้นหนึ่ง
- มองว่าเป็นจุดกึ่งกลางระหว่างเวิร์กโฟลว์ pull request ของ Github กับการส่งรับแพตช์ผ่านอีเมล
- แนวคิดหลักคือใช้แอป SSH เพื่อจัดการปฏิสัมพันธ์ส่วนใหญ่ระหว่างผู้มีส่วนร่วมกับเจ้าของโปรเจกต์ ทำทุกอย่างได้ภายในเทอร์มินัลอย่างสะดวกและครบถ้วน
- การแจ้งเตือนทำผ่าน RSS และทุกการเปลี่ยนสถานะจะนำไปสู่การสร้าง static web assets ซึ่งทั้งหมดสามารถโฮสต์ได้ด้วยเว็บเซิร์ฟเวอร์แบบไฟล์ธรรมดา
เวิร์กโฟลว์ format-patch
- เครื่องมือทำงานร่วมกันพื้นฐานที่นี่คือ format-patch
- ไม่ว่าจะส่งการเปลี่ยนแปลงโค้ดหรือรีวิวการเปลี่ยนแปลงโค้ด ทุกอย่างเกิดขึ้นจากในโค้ด
- ทั้งผู้มีส่วนร่วมและเจ้าของต่างสร้าง commit ใหม่และสร้างแพตช์ทับกันไปมา
- แบบนี้จึงไม่จำเป็นต้องมีตัวดูบนเว็บที่ให้รีวิวเวอร์ "แสดงความคิดเห็น" กับบรรทัดหนึ่งของบล็อกโค้ด ไม่จำเป็นเลย แค่ apply แพตช์ของผู้มีส่วนร่วม เขียนคอมเมนต์หรือแก้โค้ด สร้างแพตช์ใหม่ แล้วส่งแพตช์นั้นเป็น "รีวิว" ไปยังเซิร์ฟเวอร์ git
- โฟลว์นี้ทำงานแบบเดียวกันเป๊ะ แม้ในกรณีที่ผู้ใช้สองคนกำลังร่วมกันทำงานกับชุดการเปลี่ยนแปลงชุดเดียวกัน
- มันยังแก้ปัญหาการส่งหลายชุดแพตช์สำหรับการเปลี่ยนแปลงโค้ดเดียวกันได้ด้วย เพราะจะมี Patch Request กลางเพียงรายการเดียวที่รวบรวมทุกการเปลี่ยนแปลงและการทำงานร่วมกัน
- อาจหาวิธีใช้ git note เพื่อรองรับรีวิว/คอมเมนต์ได้ แต่พูดตรงๆ ว่าวิธีนั้นค่อนข้างโหด และดูเกินระดับความคุ้นเคยของผู้ใช้ git ส่วนใหญ่
- เพียงส่งรีวิวกลับมาเป็นโค้ด และเขียนหมายเหตุประกอบในโค้ดด้วยภาษาการเขียนโปรแกรมที่ใช้อยู่
- การ "จัดการ" หมายเหตุเหล่านี้และลบออกในแพตช์ถัดไปเป็นหน้าที่ของผู้มีส่วนร่วม
- ฟีเจอร์บังคับให้จัดการทุกหมายเหตุ: ถ้ายังมีหมายเหตุที่ยังไม่ถูกจัดการอยู่ในโค้ด แพตช์จะไม่ถูกรวมเข้าด้วยกัน จะละเลยไม่ได้ มิฉะนั้นมันจะถูกอัปสตรีมแบบผิดพลาด
วิธีการทำงานของ Patch Request
- Patch Request (PR) คือวิธีที่ง่ายที่สุดในการส่ง ตรวจทาน และรับการเปลี่ยนแปลงต่อคลัง git โดยทำงานดังนี้:
- ผู้มีส่วนร่วมจากภายนอกโคลนคลังเก็บ (git-clone)
- ผู้มีส่วนร่วมจากภายนอกแก้ไขโค้ด (git-add & git-commit)
- ผู้มีส่วนร่วมจากภายนอกสร้างแพตช์ (git-format-patch)
- ผู้มีส่วนร่วมจากภายนอกส่ง PR ไปยังเซิร์ฟเวอร์ SSH
- เจ้าของได้รับการแจ้งเตือน RSS เกี่ยวกับ PR ใหม่
- เจ้าของ apply แพตช์จากเซิร์ฟเวอร์ SSH มายังเครื่องโลคัล (git-am)
- เจ้าของเขียนข้อเสนอแนะลงในโค้ด (git-add & git-commit)
- เจ้าของ pipe แพตช์ไปยังเซิร์ฟเวอร์ SSH เพื่อส่งรีวิว (git-format-patch)
- ผู้มีส่วนร่วมจากภายนอกได้รับการแจ้งเตือน RSS เกี่ยวกับรีวิว PR
- ผู้มีส่วนร่วมจากภายนอก apply แพตช์อีกครั้ง (git-am)
- ผู้มีส่วนร่วมจากภายนอกตรวจทานและลบหมายเหตุในโค้ด
- ผู้มีส่วนร่วมจากภายนอกส่งแพตช์อีกชุดหนึ่ง (git-format-patch)
- เจ้าของ apply แพตช์ในเครื่องโลคัล (git-am)
- เจ้าของทำเครื่องหมายว่า PR ได้รับการอนุมัติและ push โค้ดไปยัง main (git-push)
1 ความคิดเห็น
ดูเหมือนว่าเป็นของใหม่ที่เพิ่งถูกเพิ่มเข้ามาใน Pico.sh - ชุดโอเพ่นซอร์สสำหรับจัดการเว็บเซอร์วิสทุกอย่างผ่าน SSH
ก่อนหน้านี้มีสิ่งต่อไปนี้รวมอยู่แล้ว