เวิร์กช็อปใหม่ที่สัญญาว่าจะสอน JJ VCS ( Jujutsu ) ในเวลาเพียงหนึ่งชั่วโมงได้จุดประกายการอภิปรายเกี่ยวกับว่านักพัฒนาควรยอมรับทางเลือกของ Git หรือยึดติดกับเครื่องมือแบบดั้งเดิม เวิร์กช็อป zero-to-hero speedrun มีเป้าหมายเพื่อช่วยนักพัฒนาเอาชนะอุปสรรคในการเรียนรู้เบื้องต้นที่มักจะเป็นอุปสรรคต่อการนำระบบควบคุมเวอร์ชันใหม่นี้มาใช้
โครงสร้างของเวิร์กช็อป
- วิดีโอแนะนำ: ความยาวไม่เกิน 6 นาทีที่ความเร็ว 1x
- เนื้อหาหลัก: 8 แบบฝึกหัดครอบคลุมตั้งแต่การ commit พื้นฐานไปจนถึงการแก้ไข merge conflict
- เวลาที่ใช้: 1-2 ชั่วโมงสำหรับผู้เริ่มต้นที่ไม่มีพื้นฐาน
- เอกสารประกอบ: วิดีโอเฉลยแยกสำหรับแต่ละแบบฝึกหัด
- วิดีโอสรุป: ความยาวไม่เกิน 6 นาทีที่ความเร็ว 1x
การเปลี่ยนแปลงแบบจำลองทางความคิดที่จำเป็นสำหรับการใช้งาน JJ
สมาชิกในชุมชนเน้นย้ำว่าการเรียนรู้ JJ ให้ประสบความสำเร็จต้องละทิ้งรูปแบบความคิดที่อิงจาก Git ข้อมูลเชิงลึกสำคัญที่ถูกแบ่งปันแนะนำว่านักพัฒนาควรหยุดการแปลระหว่างแนวคิดของ JJ และ Git แทนที่จะถือว่า JJ เป็นขั้นตอนเวิร์กโฟลว์ที่แตกต่างไปจากเดิมอย่างสิ้นเชิง การเปลี่ยนแปลงทางความคิดนี้ดูเหมือนจะสำคัญต่อการปลดล็อกประโยชน์ด้านประสิทธิภาพของ JJ โดยเฉพาะแนวทางในการจัดการ commits และ branches ที่แตกต่างจากเวิร์กโฟลว์ Git แบบดั้งเดิม
ข้อได้เปรียบเฉพาะของเวิร์กโฟลว์ JJ
การอภิปรายเผยให้เห็นคุณสมบัติที่น่าสนใจหลายประการที่ทำให้ JJ แตกต่างจาก Git ระบบจะสร้าง commits โดยอัตโนมัติสำหรับการเปลี่ยนแปลงไฟล์ใดๆ และแนะนำ changes เป็นแนวคิดที่ยืดหยุ่นกว่า commits แบบดั้งเดิมของ Git ผู้ใช้สามารถนำทางระหว่างเวอร์ชันต่างๆ โดยไม่ต้องใช้ฟังก์ชัน stash ของ Git แยก commits อย่างละเอียด และจัดการ merge conflicts โดยไม่ต้องแทรกแซงทันที เครื่องมือนี้ยังรองรับเวิร์กโฟลว์ขั้นสูงเช่น megamerges ที่ช่วยให้นักพัฒนาสามารถรวม feature branches หลายๆ อันและทำงานบนฟังก์ชันการทำงานที่รวมกัน
ทุกการกระทำของ jj จะถูกแปลเป็นการกระทำของ git แต่ git protocol ถูกใช้เพียงเป็นระบบไฟล์ระดับต่ำที่อยู่ข้างใต้ ซึ่งถูกแยกออกไปอย่างสมบูรณ์ คล้ายกับวิธีที่ C แยก assembly ตามที่ฉันเข้าใจ
คุณสมบัติหลักของ JJ VCS เปรียบเทียบกับ Git
| คุณสมบัติ | JJ VCS | Git |
|---|---|---|
| การสร้าง Commit | อัตโนมัติเมื่อไฟล์มีการเปลี่ยนแปลง | ต้องทำด้วยตนเองด้วย git commit |
| การเก็บงานชั่วคราว | ไม่จำเป็น - สามารถนำทางไปยัง revision ต่างๆ ได้โดยตรง | ต้องใช้ git stash |
| ความขัดแย้งในการผสาน | สามารถแก้ไขทีหลังได้ แพร่กระจายโดยอัตโนมัติ | ต้องแก้ไขทันที |
| รูปแบบ Branch | ใช้ระบบ changes-based, branch ภายในเครื่อง | branch แบบดั้งเดิมที่แชร์ผ่าน remote |
| การแก้ไขประวัติ | แยกและรวม commit ได้ง่าย | การ interactive rebasing ที่ซับซ้อน |
ความต้านทานของชุมชนและทางเลือกอื่น
ไม่ใช่ทุกคนที่ยอมรับการเปลี่ยนไปใช้ JJ โดยนักพัฒนาบางคนชอบที่จะปรับปรุงเวิร์กโฟลว์ Git ผ่านเครื่องมือที่มีอยู่ ทางเลือกอื่นเช่น Graphite.dev เสนอ stacked workflows ในขณะที่ยังคงความเข้ากันได้กับ Git อย่างเต็มรูปแบบ ซึ่งดึงดูดทีมที่ต้องการฟังก์ชันการทำงานที่ดีขึ้นโดยไม่ต้องละทิ้งระบบที่คุ้นเคย ความต้านทานนี้มักเกิดจากประสบการณ์การใช้ Git หลายปีและความกังวลเกี่ยวกับการเรียนรู้แนวคิดและคำศัพท์ใหม่ทั้งหมด
ความเป็นจริงของเส้นโค้งการเรียนรู้
แม้จะอ้างว่าเรียบง่าย แต่ข้อเสนอแนะจากชุมชนแนะนำว่าการใช้งาน JJ เกี่ยวข้องกับแรงเสียดทานเบื้องต้นที่สำคัญ นักพัฒนารายงานว่าประสิทธิภาพการทำงานลดลงในช่วงการเปลี่ยนผ่าน แม้เมื่อมาจากระบบควบคุมเวอร์ชันแบบกระจายอื่นๆ เช่น Mercurial อย่างไรก็ตาม ผู้ที่ยืนหยัดมักจะอธิบายถึงการไปถึงสถานะ JJ heaven ที่ประสิทธิภาพเกินกว่าเวิร์กโฟลว์ที่อิงจาก Git ก่อนหน้านี้
แนวทางปฏิบัติของเวิร์กช็อปที่ใช้แบบฝึกหัดและการจำลองแก้ไขความท้าทายในการเรียนรู้เหล่านี้โดยตรง แทนที่จะเป็นคำอธิบายเชิงทฤษฎี มันให้ประสบการณ์ตรงกับสถานการณ์ควบคุมเวอร์ชันจริง ซึ่งอาจลดเวลาที่ต้องใช้ในการมีประสิทธิภาพกับกระบวนทัศน์ที่แตกต่างของ JJ