บทเรียน Jujutsu ของ Evan

 (evmar.github.io)
1 คะแนน โดย GN⁺ 11 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นบทเรียนที่ออกแบบมาเพื่อให้ผู้ที่มีประสบการณ์ใช้ Git สามารถเรียนรู้ระบบควบคุมเวอร์ชัน Jujutsu(jj) ที่เรียบง่ายแต่ทรงพลังได้อย่างกระชับ
  • สำหรับผู้อ่านที่สงสัยก่อนเริ่มเรียนว่าทำไมจึงควรใช้ Jujutsu มี บทความแนะนำ Jujutsu แยกต่างหากให้
  • ยังแนะนำ ทางเลือกที่เหมาะกับระดับผู้อ่าน เช่น คู่มือเริ่มต้นแบบภาษาสนทนา เอกสารทางการที่ลงรายละเอียด และสื่อสำหรับผู้เริ่มต้นด้านการควบคุมเวอร์ชัน
  • Evan Martin เขียนเอง เพื่อคัดเลือกหัวข้อ สิ่งที่ตัดออก และลำดับการนำเสนออย่างรอบคอบ
  • ไม่ได้ใช้ AI ในการเขียนเนื้อหา และหลังจากเขียนเสร็จเกือบทั้งหมดแล้ว ใช้ AI เฉพาะเพื่อตรวจหาข้อผิดพลาด

กลุ่มผู้อ่านเป้าหมายและเส้นทางการเรียนรู้

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

แหล่งข้อมูลทางเลือกตามผู้อ่าน

  • หากแนวทางของบทเรียนนี้ไม่เหมาะกับคุณ สามารถเลือกแหล่งข้อมูลต่อไปนี้ตามระดับประสบการณ์และความชอบได้
    • Steve's Jujutsu tutorial: สื่อเริ่มต้นที่แนะนำมากที่สุด จัดทำในรูปแบบภาษาสนทนา
    • Jujutsu documentation: มีบทเรียนทางการที่ครอบคลุมรายละเอียดมากขึ้นตั้งแต่ต้น
    • Jujutsu for Everyone: สำหรับ ผู้อ่านที่ไม่เคยมีประสบการณ์ด้านการควบคุมเวอร์ชันมาก่อน

การเขียนด้วยตนเองและขอบเขตการใช้ AI

  • ข้อความทั้งหมดเขียนโดย Evan Martin เอง โดยมนุษย์เป็นผู้ตัดสินใจอย่างรอบคอบว่าจะรวมอะไร ตัดอะไร และจัดวางในลำดับใด
  • ไม่ได้ใช้ AI ในการสร้างเนื้อหา และใช้เพียงเพื่อช่วยตรวจสอบข้อผิดพลาดหลังจากเขียนไปแล้วเกือบทั้งหมด

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 11 시간 전
ความเห็นจาก Lobste.rs

  • พูดตามตรงแบบเอาชื่อเสียงเป็นเดิมพัน ฉันลองใช้ jj อยู่ประมาณสัปดาห์หนึ่ง แต่สุดท้ายก็ต้องขอให้ LLM ช่วยเพื่อลดความเจ็บปวดจากการต้องจัดการ Git โดยตรง และก็ยังไม่รู้สึกว่ามันทดแทนเวิร์กโฟลว์เดิมได้อย่างเพียงพอ
    ปกติฉันใช้แค่ git checkout, git add, git commit, git push และแทบไม่เคยเจอปัญหาเรื่อง index, stash, reset หลายแบบ, rebase ที่ค้างอยู่, หรือการ undo ที่ไม่สอดคล้องกันตามที่บทความโปรโมตพูดถึง แถมก็ไม่ค่อยใช้ monorepo ด้วย
    เลยสงสัยว่า กลุ่มเป้าหมายหลักของ Jujutsu คือใคร และกว่าจะใช้ jj ได้คล่องใช้เวลานานแค่ไหน รอบหน้าฉันอยากลองทุ่มเวลาอย่างน้อยเท่านั้นดู

    • อยากรู้ว่าให้ LLM ช่วยงานอะไรแบบเจาะจงบ้าง
      ฉันเองก็พยายามเลี่ยงงานใน Git ที่เกินกว่าพื้นฐานเหมือนกัน ดังนั้นแทนที่จะ stash แล้วสลับ branch ก็จะ clone repo ใหม่ไว้อีกที่หนึ่ง แทนที่จะเลือก commit เฉพาะการเปลี่ยนแปลงที่เกี่ยวข้องก็จะใช้ git add --all commit ทั้งหมด หรือไม่ก็ย้อนการแก้ไขใน editor ก่อน commit แล้วค่อยเอากลับมาใหม่
      ที่ทำให้ปรับตัวกับ jj ได้ง่ายส่วนหนึ่งเพราะที่ทำงานเคยใช้ Mercurial มา 7 ปี แต่ตอนนี้ การจัดวาง commit ใหม่และจัดการหลายชุดการเปลี่ยนแปลง มันง่ายมาก จนทำให้อยากทำงานซับซ้อนที่เมื่อก่อนคงเลี่ยงโดยสัญชาตญาณ
    • มุมมองมันต่างกันตามว่าคุณใช้ระบบควบคุมเวอร์ชัน (VCS) ไปเพื่ออะไร
      ถ้าแค่พัฒนาโค้ดเป็นเส้นตรงแล้วเก็บ snapshot ไว้เป็นครั้งคราว คำสั่งพวกนั้นก็เพียงพอแล้ว และ VCS เต็มรูปแบบอาจจะมากเกินไปจนใช้แค่ Dropbox ก็พอ
      สำหรับฉัน VCS คือ เครื่องมือสร้างเรื่องเล่า ที่แสดงให้เห็นว่าคุณคิดเกี่ยวกับโค้ดและลำดับชั้นของมันอย่างไร ผู้อ่านหลักคือเพื่อนร่วมงาน และผู้อ่านรองคือตัวฉันเองในอีก 10 ปีข้างหน้า ซึ่ง jj ช่วยให้จัดการสิ่งนี้ได้ลื่นไหลกว่ามาก
    • ขอให้ LLM ช่วยก็ไม่เป็นไร ฉันเองก็ทำแบบนั้นจนกว่าจะจำคำสั่งพื้นฐานที่ต้องใช้ได้
      ฉันอ่านคู่มืออยู่หลายฉบับตั้งแต่ต้นจนจบเพื่อปูพื้นศัพท์และฟีเจอร์ แล้วลองใช้อย่างต่อเนื่องในโปรเจกต์ส่วนตัวอยู่สองสามวัน ก็เริ่มคล่องกับงานพื้นฐานพอสมควร และมุมมองต่อ VCS ก็เปลี่ยนไปด้วย
      เวลา refactor หรือทำฟีเจอร์ใหญ่ ฉันจะทำให้ถึงเป้าหมายสุดท้ายก่อน แล้วค่อยแยกออกเป็นการเปลี่ยนแปลงย่อยที่รีวิวได้ง่ายและมีเหตุผลชัดเจน เช่น “แก้ eslint warning ทั้งหมด”, “refactor เพื่อเปิดเผยฟังก์ชัน”, “ย้ายส่วนเรียกใช้ A ไปฟังก์ชันใหม่”, “เพิ่มฟีเจอร์ใหม่” ซึ่ง jj split เหมาะกับงานนี้อย่างสมบูรณ์แบบ และฟีเจอร์นี้อย่างเดียวก็เพียงพอแล้วที่จะเป็นเหตุผลให้ใช้ jj
      ในทางกลับกัน git stash จัดการ stash หลายอันได้ยาก และมีจุดอันตรายด้านการใช้งานหลายอย่างที่อาจทำให้โค้ดที่เก็บไว้หายตอนเกิด conflict ได้ งานอย่างการนำ feedback จาก PR ไปใส่ใน commit ล่าง ๆ แล้ว rebase commit หรือ PR ที่อยู่ข้างบน โดยเฉพาะใน stacked PR ก็แทบเป็นฝันร้าย เพราะไม่มีตัวบอกความคืบหน้า แถมยังหยุดกลางคันหรือจัด stack ใหม่ได้ยาก ดังนั้นฉันจึงยังใช้ Graphite สำหรับจัดการ stacked PR อยู่
    • ประโยชน์ใหญ่ที่สุดที่ได้จาก jj คือ วิธีจัดการ rebase
      มีนักศึกษาบัณฑิตด้านเคมีอินทรีย์คนหนึ่งพัฒนา branch สำหรับงานวิจัยต่อเนื่องมา 4 ปีโดยไม่ merge หรือ rebase เลย ทำให้มันตามหลัง main อยู่หลายพัน commit และต้อง merge ก่อนสอบจบ เนื่องจากแทบทุก commit มี conflict ถ้าใช้ Git จะกินเวลา 1-2 สัปดาห์ และถ้าวันที่สามมีบั๊กด่วนเข้ามา ก็ต้องยกเลิก rebase ไปแก้บั๊กก่อนแล้วเริ่มใหม่ตั้งแต่ต้น พอทำเสร็จหลัง 3 สัปดาห์ ก็ยังต้อง rebase อีกรอบเพื่อให้ตรงกับ main ล่าสุด
      ใน jj merge conflict เป็นวัตถุชั้นหนึ่ง จึงค่อยกลับมาแก้ตอนมีเวลาก็ได้ และระหว่างทางต่อให้ย้ายไป commit ใหม่เพื่อแก้บั๊กด่วน ก็ไม่เสียความคืบหน้าที่ทำไว้ rebase ที่ใน Git อาจใช้เวลาหนึ่งสัปดาห์จบได้ในวันเดียว และครั้งหนึ่งยังหาเจอว่า commit ต่อเนื่อง 200 อันไม่มีการเปลี่ยนแปลงอะไรเลยหลัง merge ทำให้สามารถทิ้งงานแก้ conflict หลายหมื่นบรรทัดที่ทำมา 2 วันได้ทั้งก้อนไม่ถึง 1 นาที ระหว่าง rebase ก็ยังอัปเดต main และย้าย branch ที่กำลังทำงานให้อยู่บน main ล่าสุดได้

  • สำหรับฉันที่คุ้นกับ Git มากจนมีแค่บางครั้งที่ต้องค้นคำสั่ง บทความนี้ เป็น บทความแนะนำ Jujutsu ชิ้นแรกที่ทำให้รู้สึกสนใจจริง ๆ
    บทความก่อนหน้านี้มักเริ่มจากแนวว่า “ในที่สุดก็หนีจาก command line interface อันแสนน่ากลัวของ Git ได้แล้ว” ซึ่งแม้จะเข้าใจว่าจุดแปลกของ Git และความลำบากของคนอื่นคืออะไร แต่ถ้อยคำแบบนั้นทำให้ฉันมอง Jujutsu เป็นอะไรที่ไม่เกี่ยวกับตัวเอง เหมือนนิยายรักหรือ beef vindaloo

    • เหตุผลที่อธิบายความสนุกของ jj ได้ยาก คือคุณสมบัติโดยนัยบางอย่างที่เคยคิดว่าทุก VCS ต้องมี จริง ๆ แล้วไม่ได้มี และ atomic operation ก็เรียบง่ายกว่ามาก
      มันเลยยากที่จะคิดคำโปรยดี ๆ สุดท้ายคำอธิบายทั้งหมดจึงถูกย่นเหลือแค่ว่า “มันไม่ใช่ Git” และฉันเองก็มักอธิบายเรื่องนี้ได้ไม่ดีนัก
    • ใน Git ถ้าใช้ GUI อย่าง Sublime Merge ร่วมกับคำสั่งที่ปรับแต่งเองอีกเล็กน้อย ก็แทบจะแก้ปัญหาที่พูดถึงตรงนี้ได้เกือบหมด
      ต่างจาก Git GUI ตัวอื่น มันพยายามยึดตามคำสั่ง Git จริงให้มากที่สุด โดยแค่เปลี่ยนไวยากรณ์ที่เข้าใจยากให้เป็นเมนูและปุ่ม และก็ไม่ได้ซ่อนว่าการกระทำแต่ละอย่างเทียบกับคำสั่งอะไร เพราะจะบันทึกไว้ใน status bar ด้วย ถ้ามี Sublime JJ ออกมา ฉันพร้อมย้ายทันที
    • คำอธิบายที่ทำให้ฉันอยากลอง jj มากที่สุดคือ Git ที่อยู่ในสถานะ interactive rebase ตลอดเวลา