Jujutsu (jj) ระบบควบคุมเวอร์ชันสมัยใหม่ที่ใช้ Git เป็น backend กำลังได้รับการยอมรับที่เพิ่มขึ้นในหมู่นักพัฒนาที่รายงานการปรับปรุงเวิร์กโฟลว์อย่างมีนัยสำคัญเมื่อเทียบกับการใช้ Git แบบดั้งเดิม ระบบนี้สัญญาว่าจะให้โมเดลทางความคิดที่เรียบง่ายขณะที่ยังคงความเข้ากันได้อย่างเต็มรูปแบบกับ Git repositories ที่มีอยู่ ทำให้นักพัฒนารายบุคคลสามารถนำมาใช้ได้โดยไม่ต้องเปลี่ยนแปลงทั้งทีม
อัตราการคงอยู่ของผู้ใช้ที่ยอดเยี่ยมขับเคลื่อนการเติบโตของชุมชน
แง่มุมที่โดดเด่นที่สุดของการยอมรับ Jujutsu ดูเหมือนจะเป็นอัตราการคงอยู่ในหมู่ผู้ใช้ที่ให้การทดลองใช้อย่างจริงจัง การอฏิปรายในชุมชนเผยให้เห็นอัตราการเปลี่ยนแปลงที่สูงผิดปกติ โดยนักพัฒนารายงานอย่างสม่ำเสมอว่าเมื่อพวกเขาใช้เวลาหนึ่งสัปดาห์เรียนรู้ระบบแล้ว พวกเขาไม่ค่อยกลับไปใช้ Git อีก รูปแบบนี้ปรากฏขึ้นในหลายกระทู้การอภิปราย ซึ่งบ่งชี้ว่าการลงทุนเรียนรู้ในช่วงแรกให้ผลตอบแทนอย่างรวดเร็วสำหรับผู้ใช้ส่วนใหญ่
ระบบนี้แก้ไขจุดเจ็บปวดหลายประการที่ผู้ใช้ Git มักพบ โดยเฉพาะอย่างยิ่งเกี่ยวกับการดำเนินการ rebasing ที่ซับซ้อนและการจัดการการเปลี่ยนแปลงที่เกี่ยวข้องหลายรายการ ไม่เหมือนกับแนวทาง modal ของ Git ที่ต้องการให้ผู้ใช้นำทางสถานะต่างๆ ระหว่างการดำเนินการเช่น rebasing Jujutsu รักษาอินเทอร์เฟซที่สอดคล้องกันตลอดการดำเนินการทั้งหมด
เวิร์กโฟลว์ที่เรียบง่ายสำหรับการดำเนินการที่ซับซ้อน
หนึ่งในข้อได้เปรียบหลักของ Jujutsu อยู่ที่การจัดการสถานการณ์ที่ยากลำบากใน Git เช่น การจัดการ pull requests ที่ขึ้นต่อกันหรือการแบ่งงานข้าม branches แบบขนาน เมื่อนักพัฒนาต้องการแก้ไข commit ก่อนหน้าในชุดของการเปลี่ยนแปลงที่เกี่ยวข้องกัน Git โดยทั่วไปต้องการ rebasing แบบแมนนวลของ commits ที่ตามมาทั้งหมด Jujutsu ทำให้กระบวนการนี้เป็นอัตโนมัติ โดยอัปเดต revisions ที่ขึ้นต่อกันโดยอัตโนมัติเมื่อ parent commits เปลี่ยนแปลง
ระบบนี้ยังแนะนำแนวทางที่แตกต่างในการ staging การเปลี่ยนแปลง แทนที่จะเป็น staging area ที่ใช้ index ของ Git Jujutsu ถือว่า working copy เป็น commit เอง นักพัฒนาสามารถใช้คำสั่งเช่น jj split เพื่อแยกการเปลี่ยนแปลงไปยัง revisions ต่างๆ หรือ jj squash เพื่อรวมงาน ให้ความยืดหยุ่นคล้ายกับ git add -p แต่มีความสามารถในการแก้ไขที่ทรงพลังกว่า
คำสั่ง Jujutsu หลักเปรียบเทียบกับ Git
| การดำเนินการ | คำสั่ง Git | คำสั่ง Jujutsu |
|---|---|---|
| เลือกการเปลี่ยนแปลงแบบโต้ตอบ | git add -p |
jj squash -i |
| แยกการเปลี่ยนแปลง | git reset -p + git add -p |
jj split |
| แก้ไข commit ก่อนหน้า | git rebase -i |
jj edit <revision> |
| สร้าง branch ใหม่ | git checkout -b <branch> |
jj new |
| ยกเลิกการดำเนินการ | git reflog + git reset |
jj op undo <operation> |
คุณสมบัติการแก้ไขความขัดแย้งและการกู้คืน
Jujutsu จัดการ merge conflicts เป็น first-class citizens แทนที่จะเป็นการบล็อกการดำเนินการ เมื่อความขัดแย้งเกิดขึ้น ระบบจะทำเครื่องหมายไว้และอนุญาตให้นักพัฒนาทำงานต่อไป แก้ไขความขัดแย้งตามความสะดวกแทนที่จะถูกบังคับให้แก้ไขทันที แนวทางนี้ลดการขัดจังหวะต่อเวิร์กโฟลว์ที่ผู้ใช้ Git มักประสบระหว่าง merges ที่ซับซ้อน
ระบบนี้ยังรวมฟังก์ชัน undo ที่ครอบคลุมผ่าน operation log ทุกการกระทำที่ดำเนินการใน Jujutsu repository จะถูกบันทึก ทำให้นักพัฒนาสามารถคืนสถานะ repository ทั้งหมดไปยังจุดก่อนหน้าใดก็ได้ คุณสมบัตินี้ให้ตาข่ายนิรภัยที่นักพัฒนาหลายคนรู้สึกเป็นอิสระ โดยเฉพาะเมื่อดำเนินการแก้ไขประวัติที่ซับซ้อน
คุณสามารถทำลาย repo ของคุณใน git และนั่นแหละ -- คุณเจ๊งแล้ว หรือคุณหาเวทมนตร์สุดขั้วบนอินเทอร์เน็ตที่ช่วยคุณได้ ด้วย jj คุณแค่ jj op undo <operation_id_that_fucked_your_repo> และคุณก็โอเค
ข้อได้เปรียบของ Workflow เหนือ Git
- Automatic Rebasing: คอมมิตที่ขึ้นต่อกันจะอัปเดตโดยอัตโนมัติเมื่อคอมมิตหลักมีการเปลี่ยนแปลง
- Conflict as First-Class: ความขัดแย้งไม่ได้ขัดขวางการทำงานและสามารถแก้ไขได้ตลอดเวลา
- No Modal States: อินเทอร์เฟซที่สม่ำเสมอโดยไม่มีโหมด rebase/merge พิเศษ
- Universal Undo: ประวัติการดำเนินงานที่สมบูรณ์ช่วยให้สามารถย้อนกลับไปยังสถานะใดก็ได้ของ repository
- Working Copy as Commit: ขจัดความซับซ้อนของ staging area พร้อมทั้งให้พลังมากขึ้น
การยอมรับในองค์กรและความเข้ากันได้
Jujutsu ประสบความสำเร็จในสภาพแวดล้อมองค์กร ด้วยการนำไปใช้ในบริษัทเทคโนโลยีใหญ่รวมถึง Google ที่ใช้เป็น frontend สำหรับระบบ monorepo ภายในที่ใช้ Perforce การออกแบบที่ไม่ขึ้นกับ backend ทำให้สามารถทำงานกับระบบจัดเก็บข้อมูลต่างๆ ขณะที่นำเสนออินเทอร์เฟซที่สอดคล้องกันให้กับผู้ใช้
ชั้น compatibility ของ Git หมายความว่าทีมสามารถยอมรับ Jujutsu แบบค่อยเป็นค่อยไป โดยสมาชิกบางคนใช้มันขณะที่คนอื่นๆ ยังคงใช้ Git ใน repositories เดียวกัน การทำงานร่วมกันนี้ขจัดอุปสรรคทั่วไปของการต้องการการยอมรับเป็นเอกฉันท์ของทีมสำหรับการเปลี่ยนแปลงระบบควบคุมเวอร์ชัน
การรองรับ Backend ของ Jujutsu
- Git Backend: Backend หลักสำหรับความเข้ากันได้กับ repositories ของ Git ที่มีอยู่
- Native Backend: รูปแบบการจัดเก็บข้อมูลของ Jujutsu เองสำหรับ repositories ใหม่
- Piper Backend: การผสานรวมกับระบบภายในของ Google ที่ใช้ Perforce เป็นฐาน
- Future Backends: ออกแบบมาเพื่อรองรับระบบควบคุมเวอร์ชันเพิ่มเติม
เส้นโค้งการเรียนรู้และระบบนิเวศเครื่องมือ
แม้ว่า Jujutsu จะมีข้อได้เปรียบที่สำคัญ แต่ก็ต้องการการเรียนรู้แนวคิดและคำสั่งใหม่ ระบบใช้คำศัพท์ที่แตกต่างจาก Git โดยอ้างถึง revisions แทน commits และ bookmarks แทน branches อย่างไรก็ตาม ข้อเสนอแนะจากชุมชนบ่งชี้ว่านักพัฒนาโดยทั่วไปจะมีประสิทธิภาพภายในหนึ่งวันและสะดวกสบายอย่างเต็มที่ภายในหนึ่งสัปดาห์
ระบบนิเวศเครื่องมือรอบ Jujutsu ยังคงพัฒนาเมื่อเทียบกับภูมิทัศน์ที่เป็นผู้ใหญ่ของ Git แม้ว่าอินเทอร์เฟซบรรทัดคำสั่งเช่น jjui และ lazyjj จะให้ประสบการณ์แบบโต้ตอบ แต่การรวม IDE ยังคงจำกัด นักพัฒนาบางคนรายงานสิ่งนี้เป็นการพิจารณาเมื่อประเมินการยอมรับ โดยเฉพาะในทีมที่พึ่งพาเวิร์กโฟลว์ Git ที่ใช้ IDE อย่างหนัก
แม้จะเป็นระบบที่ค่อนข้างใหม่ Jujutsu ดูเหมือนจะได้รับความสนใจในหมู่นักพัฒนาที่แสวงหาเวิร์กโฟลว์การควบคุมเวอร์ชันที่ทรงพลังและใช้งานง่ายมากขึ้น การรวมกันของความเข้ากันได้กับ Git และความสามารถที่เพิ่มขึ้นทำให้เป็นตัวเลือกที่น่าสนใจสำหรับทั้งนักพัฒนารายบุคคลและองค์กรที่ต้องการปรับปรุงกระบวนการพัฒนาของพวกเขา
อ้างอิง: Jujutsu For Busy Devs