Steve Klabnik ผู้บุกเบิก Rust เดิมพันกับ Jujutsu VCS ออกจาก Oxide เพื่อสร้างแพลตฟอร์มสำหรับนักพัฒนารุ่นใหม่

ทีมชุมชน BigGo
Steve Klabnik ผู้บุกเบิก Rust เดิมพันกับ Jujutsu VCS ออกจาก Oxide เพื่อสร้างแพลตฟอร์มสำหรับนักพัฒนารุ่นใหม่

ภูมิทัศน์ของระบบควบคุมเวอร์ชันซึ่งถูกครอบงำมายาวนานโดย Git กำลังมีผู้ท้าชิงที่น่าสนใจอย่าง Jujutsu (jj) ซึ่งเป็นระบบควบคุมเวอร์ชันรุ่นใหม่ที่กำลังได้รับความนิยมผ่านการยอมรับในระดับรากหญ้าและการสนับสนุนจากบริษัทขนาดใหญ่ เทคโนโลยีนี้เพิ่งสร้างความสนใจเมื่อ Steve Klabnik ผู้สนับสนุน Rust ชื่อดังและผู้ร่วมเขียนหนังสือ The Rust Programming Language ประกาศว่ากำลังจะออกจาก Oxide เพื่อเข้าร่วมกับ ERSC บริษัทใหม่ที่กำลังสร้างแพลตฟอร์มการทำงานร่วมกันสำหรับนักพัฒนาที่มี jj เป็นศูนย์กลาง

ไฮไลท์ไทม์ไลน์การนำไปใช้:

  • 2012: เปิดตัว Rust 0.5 (บริบทสำหรับกรอบการประเมินเทคโนโลยีของ Klabnik)
  • เมื่อเร็วๆ นี้: jj ย้ายจาก GitHub ส่วนตัวไปยังองค์กร jj-vcs
  • 2024: จัดการประชุม jj ครั้งแรก
  • 2025: Klabnik ประกาศย้ายไปที่ ERSC (มีผลเดือนหน้า)
  • ปัจจุบัน: การนำไปใช้เติบโตขึ้นที่ Google และผ่านชุมชนรากหญ้า

เหตุใดนักพัฒนาจึงหันมาใช้ Jujutsu

การสนทนาในชุมชนเผยให้เห็นว่าความน่าสนใจของ jj อยู่ที่แนวทางเฉพาะตัวในการจัดการเวอร์ชันที่ทั้งเรียบง่ายและทรงพลังกว่า Git ผู้ใช้รายงานว่า jj ช่วยขจัดจุดที่สร้างความยุ่งยากหลายอย่างของ Git ออกไป ในขณะเดียวกันก็แนะนำการปรับปรุงขั้นตอนการทำงานที่รู้สึกก้าวล้ำ การทำงานของฟังก์ชันการรีเบสอัตโนมัติโดดเด่นเป็นพิเศษในฐานะข้อได้เปรียบหลัก - เมื่อคุณแก้ไข commit ที่อยู่กลาง branch, jj จะส่งต่อการเปลี่ยนแปลงเหล่านั้นไปยัง commit ที่เกี่ยวข้องโดยอัตโนมัติ ซึ่งช่วยขจัดโซ่ของการรีเบสด้วยมือที่สร้างปัญหาให้กับขั้นตอนการทำงานของ Git

มันให้ความรู้สึกเป็นอิสระในหลายแง่มุม คุณสามารถทำทุกอย่างที่ทำได้กับ git ได้ แต่บางสิ่งเหล่านั้นไม่จำเป็นต้องใช้หลายขั้นตอนหรือการทำซ้ำแบบเดิมๆ jj rebase + commitable conflicts + jj undo = อิสรภาพและความสบายใจ

คำสั่ง jj undo ได้กลายเป็นที่ชื่นชอบเป็นพิเศษในหมู่ผู้ใช้ ไม่เหมือนกับการทำงานบางอย่างของ Git ที่บางครั้งไม่สามารถย้อนกลับได้, jj จะบันทึกประวัติการทำงานซึ่งอนุญาตให้ผู้ใช้ทดลองได้อย่างปลอดภัย โดยรู้ว่าพวกเขาสามารถย้อนกลับไปยังสถานะก่อนหน้าได้เสมอ ไม่ว่าพวกเขาจะรันคำสั่งอะไรไปแล้ว เกราะป้องกันความปลอดภัยนี้ส่งเสริมให้มีการปรับ重构โค้ดและการสำรวจที่กล้าหาญมากขึ้น

คุณสมบัติหลักของ Jujutsu (jj) เมื่อเปรียบเทียบกับ Git:

  • Automatic rebase cascading: การแก้ไข commits จะอัปเดต dependent commits โดยอัตโนมัติ
  • Operation log: ประวัติที่สมบูรณ์ของการดำเนินการทั้งหมดใน repository
  • Universal undo: jj undo ย้อนกลับการดำเนินการใดๆ ได้ ไม่ใช่แค่ commits เท่านั้น
  • Pluggable backends: ทำงานได้กับ Git repositories หรือ backends อื่นๆ เช่น Piper ของ Google
  • Conflict management: สามารถ commit conflicts ได้ ทำให้ส่งงานบางส่วนได้
  • No staging area: ตัดขั้นตอน git add ออกจาก workflow

กลยุทธ์การนำไปใช้แบบค่อยเป็นค่อยไปและการสนับสนุนจากองค์กร

ข้อได้เปรียบเชิงกลยุทธ์ที่สำคัญที่สุดของ Jujutsu อาจเป็นความเข้ากันได้กับ repository ของ Git ซึ่งทำให้ทีมสามารถนำมาใช้แบบค่อยเป็นค่อยไปได้โดยไม่ขัดจังหวะขั้นตอนการทำงานที่มีอยู่ สิ่งนี้แตกต่างอย่างมากจากเครื่องมือระบบควบคุมเวอร์ชันรุ่นใหม่อื่นๆ ที่ต้องการการย้ายระบบนิเวศทั้งหมด ที่ Oxide, Klabnik และเพื่อนร่วมงานได้สาธิตรูปแบบการนำไปใช้แบบค่อยเป็นค่อยไปนี้ โดยเริ่มจากนักพัฒนารายบุคคลและขยายออกไปอย่างเป็นธรรมชาติ

การนำไปใช้ภายใน Google อย่างกว้างขวางเป็นการยืนยันที่สำคัญ แม้ว่า jj จะเชื่อมต่อกับระบบหลังบ้านที่เป็นของ Google เองชื่อ Piper แทนที่จะเป็น Git ในบริบทนี้ แต่ขนาดของการใช้งานภายใน monorepo ที่ใหญ่ที่สุดแห่งหนึ่งของโลกก็แสดงให้เห็นถึงความพร้อมสำหรับองค์กรของเครื่องมือนี้ การสนับสนุนจากองค์กรนี้ เมื่อรวมกับความกระตือรือร้นจากระดับรากหญ้าแล้ว สร้างพลวัตการเติบโตที่มีพลังซึ่งชวนให้นึกถึงความสำเร็จของภาษาโปรแกรมมิ่งในยุคเริ่มต้น

เส้นทางข้างหน้า: อุปสรรคและโอกาส

แม้จะมีกระแสความสนใจที่เพิ่มขึ้น แต่ jj ยังต้องเผชิญกับอุปสรรคหลายประการในการนำไปใช้ เส้นโค้งการเรียนรู้ดูจะชันที่สุดสำหรับผู้เชี่ยวชาญ Git ที่ต้องลืมขั้นตอนการทำงานที่ฝังลึกในตัว ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุไว้ ผู้ที่รู้จักโครงสร้างภายในของ Git เป็นอย่างดีและได้ทุ่มเทเวลาและความใส่ใจในขั้นตอนการทำงานของพวกเขามักจะต่อสู้ดิ้นรนกับ jj นิดหน่อย เพราะ jj นั้นแตกต่าง ในทางกลับกัน ผู้ที่เพิ่งเริ่มใช้ระบบควบคุมเวอร์ชันมักพบว่า jj เข้าใจง่ายกว่า

การพัฒนาระบบนิเวศของเครื่องมือยังคงมีความสำคัญ สมาชิกในชุมชนได้ระบุถึงความจำเป็นในการรวมกับ IDE ที่ดีขึ้น โดยเฉพาะส่วนขยายสำหรับ VSCode ที่มีประสิทธิภาพ และการที่ LLM รู้จักและเข้าใจ jj มากขึ้น ปัจจุบัน ผู้ช่วยทางการเขียนโค้ดด้วย AI มักไม่รู้จักคำสั่ง jj หรือให้ไวยากรณ์ที่ผิดพลาด สร้างความยุ่งยากให้กับนักพัฒนาที่คุ้นเคยกับการทำงานร่วมกับ AI

แพลตฟอร์ม ERSC ที่กำลังจะมาถึงแสดงถึงความพยายามที่ทะเยอทะยานที่สุดในการสร้างระบบนิเวศที่ครอบคลุมรอบๆ jj แม้ว่ามักจะถูกอธิบายว่าเป็น jjhub ในการสนทนาของชุมชน แต่แพลตฟอร์มนี้มีเป้าหมายที่จะนำเสนอมากกว่าแค่ฟังก์ชันการทำงานแบบ GitHub สำหรับ repository ของ jj ชุดคุณสมบัติที่แน่นอนยังคงไม่ถูกกำหนด แต่ความรู้สึกของชุมชนส่วนใหญ่สนับสนุนข้อมูลการรีวิวโค้ดที่เก็บไว้ในเครื่อง, การออกแบบที่ให้ความสำคัญกับ CLI เป็นอันดับแรก และความสามารถที่ทำงานแบบออฟไลน์ได้

ความคล้ายคลึงของชุมชนกับ Rust ในยุคเริ่มต้น

พลวัตของชุมชน jj มีความคล้ายคลึงกับชุมชน Rust ในช่วงปีแรกๆ อย่างน่าทึ่ง ทั้งสองโครงการดึงดูดผู้ใช้รุ่นแรกๆ ที่กระตือรือร้น ซึ่งชื่นชอบไม่เพียงแต่ข้อดีทางเทคนิค แต่ยังรวมถึงวัฒนธรรมชุมชนที่เป็นมิตร การมีส่วนร่วมของ Klabnik สะท้อนให้เห็นถึงการสนับสนุน Rust ในยุคเริ่มต้นของเขา บ่งชี้ว่าเขาเห็นศักยภาพที่คล้ายกันในแนวทางของ jj ในการแก้ปัญหาพื้นฐานของขั้นตอนการทำงาน

การเปรียบเทียบนี้ขยายไปถึงรูปแบบการนำไปใช้ด้วย เช่นเดียวกับ Rust ในยุคเริ่มต้น, jj ดึงดูดนักพัฒนาที่รู้สึกหงุดหงิดกับข้อจำกัดของเครื่องมือที่มีอยู่ แต่ต้องการความอดทนในช่วงที่ระบบนิเวศกำลังเติบโต การมีอยู่ของผู้ดูแลหลักที่ทุ่มเท ซึ่งรวมถึง Martin ผู้สร้างและตอนนี้ก็มี Klabnik ด้วย นำมาซึ่งความมั่นคงในช่วงการเติบโตนี้

ในขณะที่ภูมิทัศน์ของระบบควบคุมเวอร์ชันกำลังพัฒนาไป jj ถือเป็นความท้าทายที่น่าเชื่อถือที่สุดต่อการครอบงำของ Git นับตั้งแต่ Mercurial การผสมผสานระหว่างนวัตกรรมทางเทคนิค กลยุทธ์การนำไปใช้ที่เน้นปฏิบัติได้จริง และการสนับสนุนจากองค์กรที่เพิ่มขึ้น ตำแหน่งมันเป็นเทคโนโลยีที่ควรจับตามองอย่างใกล้ชิดในอีกหลายปีข้างหน้า

อ้างอิง: I see a future in jj