Jujutsu สำหรับทุกคน

 (jj-for-everyone.github.io)
2 คะแนน โดย GN⁺ 2025-09-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เอกสารนี้เป็นบทสอนสำหรับผู้เริ่มต้นที่สอน Jujutsu(VCS) แบบเป็นขั้นเป็นตอนด้วยโครงสร้าง แบ่งเป็นเลเวล เพื่อให้ทำตามได้แม้ไม่มีประสบการณ์กับ Git
  • แม้จะตั้งอยู่บนสมมติฐานว่าผู้อ่านใช้เทอร์มินัล แต่ก็ครอบคลุมตั้งแต่ พื้นฐานการใช้เทอร์มินัล และอธิบายคำสั่งหลักโดยเน้น Linux/macOS โดยแนะนำให้ผู้ใช้ Windows ใช้ WSL
  • ลำดับการเรียนรู้ถูกออกแบบให้สร้างพื้นฐาน การใช้งานเบื้องต้น·การทำงานร่วมกัน·การแก้ปัญหา ในเลเวล 1~3 แล้วค่อยขยายไปสู่ การเขียนประวัติใหม่·เวิร์กโฟลว์ขั้นสูง ในเลเวลที่สูงขึ้น
  • เพื่อรองรับกรณีที่สถานะระหว่างทำบทสอนเกิดความสับสน มี สคริปต์ reset สำหรับย้อนกลับไปยังจุดเริ่มต้นของแต่ละบท จึงได้ สภาพแวดล้อมการเรียนรู้ที่ทำซ้ำได้
  • สำหรับคำถามว่าทำไมต้องใช้ Jujutsu แทน Git เอกสารนี้ให้เหตุผลด้วย ความเข้ากันได้กับ Git, การลดความยากในการเรียนรู้, และ ความสามารถขั้นสูง พร้อมอัปเดตตาม Jujutsu 0.32 รุ่นล่าสุด

บทนำ(Introduction)

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

วิธีอ่าน(How to read this tutorial)

  • เนื้อหาถูกจัดเป็น รายเลเวล และออกแบบให้เรียนโดย ฝึกปฏิบัติจริงหลังจบแต่ละเลเวล ก่อนค่อยไปต่อเลเวลถัดไป
  • หากมีเป้าหมายเพื่อ การทำงานร่วมกัน แนะนำให้เรียนเลเวล 1 และ 2 ต่อเนื่องกัน
  • ภาพรวมของแต่ละเลเวล
    • เลเวล 1: ชุดเริ่มต้น ขั้นต่ำที่จำเป็น สำหรับงานส่วนตัว เหมาะกับระดับนักเรียนที่จัดการงานของตนเองคนเดียว
    • เลเวล 2: ชุดขั้นต่ำสำหรับการทำงานร่วมกัน จำเป็นสำหรับโปรเจกต์ทีมนักเรียนและนักพัฒนาที่ทำงานจริง
    • เลเวล 3: พื้นฐานการ แก้ปัญหา เช่น การแก้ conflict และการกู้คืน อยู่ในระดับความชำนาญเฉลี่ยของนักพัฒนา
    • เลเวล 4: สร้างประวัติที่สะอาดด้วย การเขียนประวัติใหม่ ซึ่งจำเป็นต่อการผ่าน มาตรฐานคุณภาพ ของบางโปรเจกต์
    • เลเวล 5: ตัวเร่งประสิทธิภาพ·เวิร์กโฟลว์ขั้นสูง·CLI แบบเฉพาะทาง·ทฤษฎี คือระดับ มาสเตอร์ ของ Jujutsu
    • เลเวล 6: หัวข้อเฉพาะสถานการณ์ เช่น แท็ก·submodule·workspace แนะนำให้อ้างอิงเมื่อจำเป็น

ปุ่มลัด(Keyboard shortcuts)

  • รองรับ การย้ายระหว่างบท ด้วยปุ่มลูกศรซ้ายขวา
  • รองรับ การค้นหา ภายในหนังสือด้วย S หรือ /
  • แสดงช่วยเหลือด้วย ? และซ่อนด้วย Esc

รีเซ็ตความคืบหน้า(Reset your progress)

  • เนื่องจากสถานะของรีโพตัวอย่าง เชื่อมต่อกับบทถัดไป หากสถานะสูญหายอาจทำให้ไปต่อไม่ได้
  • เพื่อแก้ปัญหานี้ จึงมี สคริปต์ reset.sh สำหรับ กู้คืนไปยังจุดเริ่มต้นของบท
  • ต้นแต่ละบทมี คำสั่ง reset ที่ตรงตามบทนั้น รวมอยู่แล้ว จึงสามารถทำซ้ำได้ด้วยการ คัดลอกและวาง
  • แนะนำให้ ตรวจสอบเนื้อหาสคริปต์ ก่อนรัน โดยตัวมันเองเป็นเพียงการทำงานง่าย ๆ ระดับ ชุดคำสั่งที่รันด้วยมือ
  • คุณสมบัติหลักของสคริปต์
    • ใช้ JJ_CONFIG=/dev/null เพื่อ ตัดผลกระทบจากการตั้งค่าของผู้ใช้
    • สร้างรีโพตัวอย่าง, เชื่อมต่อ colocate Git, ตั้งค่าข้อมูลผู้ใช้, และสร้างสถานการณ์ต่อเนื่องอย่าง commit/push/fetch/rebase
    • ออกแบบให้รับ คีย์เวิร์ดของแต่ละบท เป็นอาร์กิวเมนต์ แล้วแตกแขนงเพื่อ จบการทำงานสำเร็จ ที่จุดนั้น

อัปเดตให้ทันสมัย(Stay up to date)

  • ทั้งบทสอนและ Jujutsu ยังคง พัฒนาอย่างต่อเนื่อง และสามารถรับประกาศการเปลี่ยนแปลงใหญ่ได้ด้วยการ ติดตาม Releases ของรีโพบทสอน
  • เอกสารนี้ระบุว่าอัปเดตล่าสุดตาม Jujutsu 0.32 (สิงหาคม 2025)
  • มีคำแนะนำการตั้งค่า การแจ้งเตือนอัปเดต บน GitHub ผ่าน Watch → Custom → Releases

การควบคุมเวอร์ชันจำเป็นอย่างไร(What is version control and why use it?)

  • เป็นวิธีจัดการการสะสมงานแบบค่อยเป็นค่อยไปที่ใช้ได้ไม่เฉพาะกับซอฟต์แวร์ แต่ยังรวมถึง งานเขียนเอกสารอย่าง Typst
  • รองรับทั้งการ ย้อนกลับไปยังสถานะในอดีต และ การทำงานพร้อมกันของหลายคน อย่างปลอดภัย
  • เมื่อคุณต้องการ เครื่องมือควบคุมที่ละเอียดกว่า การสำรองข้อมูลทั่วไปหรือ collaborative editor, Jujutsu ก็เป็นตัวเลือกที่เหมาะสม

ทำไมต้อง Jujutsu(Why Jujutsu instead of Git?)

  • ความเข้ากันได้กับ Git: ทำงานร่วมกับรีโพ Git เดิมได้แบบ ไม่สูญเสียข้อมูล และยังใช้ เครื่องมือผสานกับ Git ส่วนใหญ่ได้ตามเดิม
  • เรียนรู้ง่ายกว่า: เมื่อเทียบกับ UI ของ Git ที่ ซับซ้อนและไม่ค่อยตรงสัญชาตญาณ Jujutsu ให้ความสามารถเดียวกันด้วย ความซับซ้อนที่ต่ำกว่า
  • ความสามารถที่ทรงพลังกว่า: นอกจากเรียนรู้ง่ายแล้ว ยังมี ฟีเจอร์สำหรับ power user จำนวนมาก ทำให้ ขยายเวิร์กโฟลว์ ได้
  • ข้อเสียและสิ่งที่ควรพิจารณา
    • ในการสื่อสารอาจมีภาระจาก การแมปแนวคิดเข้ากับวัฒนธรรมที่ยึดศัพท์ Git เป็นหลัก แต่มีโอกาสบรรเทาได้ด้วย การชักชวนเพื่อนร่วมทีม
    • เนื่องจากยังค่อนข้างใหม่ จึงมีบางกรณีที่ ยังไม่มีบางฟีเจอร์ของ Git และหากจำเป็นสามารถ fallback ไปใช้ Git โดยตรง ได้
    • CLI ยังอยู่ใน ช่วงปรับเสถียรภาพ คำสั่งบางอย่างอาจเปลี่ยนแปลงได้ จึงแนะนำให้ ติดตามรีลีสของบทสอน เพื่อดูความเปลี่ยนแปลง

ความคืบหน้าการเรียน(Completed & Next)

  • ปัจจุบันเน้นเลเวล 1~3 เพื่อให้ซึมซับลำดับงานจริงตั้งแต่ ติดตั้ง→เริ่มต้นใช้งาน→log/commit→remote/push·clone→branch/merge→rebase→navigation→ย้อนกลับ/กู้คืน→แก้ conflict→เก็บงานให้เรียบร้อย
  • และเสนอแนวทางเพิ่มความชำนาญแบบค่อยเป็นค่อยไป โดยไปเรียนต่อเรื่อง การเขียนประวัติใหม่·เวิร์กโฟลว์ขั้นสูง·หัวข้อเฉพาะทาง ในเลเวลที่สูงขึ้น

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

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

 
GN⁺ 2025-09-01
ความเห็นจาก Hacker News

  • เหมือนผมจะเห็นแต่บทความชื่นชม jj มาหลายสิบชิ้นแล้ว บทช่วยสอนนี้ก็คล้ายกัน แต่ตอนนี้ผมอ่านข้อดีมาพอแล้วเลยสนใจข้อเสียและจุดที่ใช้งานไม่สะดวกมากกว่า ผมลองใช้ jj แล้วก็มีทั้งข้อดีข้อเสีย ผมใช้เวิร์กโฟลว์ที่แชร์ branch กับเพื่อนร่วมงานแล้วค่อย ๆ สะสม commit ต่อบ่อย ๆ แต่ jj ไม่มี branch ที่ตั้งชื่อไว้ ทำให้ใช้งานลำบากกว่า git (ถึงจะใช้ alias อย่าง tug ก็ยังเหมือนเดิม) ส่วน “Tracking remote bookmarks” ในบทช่วยสอนก็ดูยังไม่ค่อยสะดวกสำหรับผม อีกอย่างที่ไม่สะดวกคือ jj ใช้ light clone แบบ git clone --filter=blob:none ของ git ไม่ได้ เลยสงสัยว่าตอนนี้แก้แล้วหรือยัง

    • jj มี branch ที่ตั้งชื่อไว้ และใน jj เรียกว่า “bookmarks” ถ้าติดตาม remote bookmark อยู่ jj git fetch จะซิงก์ local กับ remote ให้

    • หนึ่งในจุดที่ทำให้ผมลำบากคือบางครั้ง jj เหมือนทำการเปลี่ยนแปลงของผมหายไปแบบสุ่ม ๆ ทั้งที่ทำงานใน Cursor และไม่ได้ mutating repo ด้วย jj เลย (มีแค่ jj status, jj log ประมาณนั้น) แต่พอกลับมาดูทีหลังก็มีบางครั้งที่การเปลี่ยนแปลงหายไป และมักจะมีข้อความ "stale workspace" โผล่มาด้วย ไม่แน่ใจว่าเป็นเพราะ IDE หรือเพราะ monorepo ขนาดใหญ่มาก แต่ทรมานจริง ๆ ถึงอย่างนั้นผมก็ชอบความยืดหยุ่นของ jj มาก

    • มีการพูดคุยเรื่องทำให้เวิร์กโฟลว์ tug ง่ายขึ้นอีกหน่อยที่ https://github.com/jj-vcs/jj/discussions/3549

    • ที่บอกว่า jj ไม่มี named branch นั้นไม่ถูกต้อง คุณแค่ต้องกำหนดเองด้วย jj branch set -r@ XYZ ซึ่งอาจดูยุ่งยากนิดหน่อย แต่ทำแค่ครั้งเดียวตอน push ก็พอ หรือจะย้าย branch ด้วย jj git push --named XYZ=@ ก็ได้

    • เรื่องที่ jj ยังไม่รองรับ light clone (git clone --filter=blob:none) ก็ยังไม่ได้รับการแก้ไข

  • มีการบอกว่า “Jujutsu ทรงพลังกว่า Git” แต่ไม่ได้อธิบายชัด ๆ ว่าทรงพลังกว่าตรงไหน เลยสงสัยว่าทำไมถึงควรใช้ มันดูเหมือนคำพูดสวยหรูเฉย ๆ

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

    • ตัวอย่างเช่น คุณสร้าง branch ใหม่จาก Main และวางแผนจะส่งเป็น PR ทีหลัง คุณสะสม commit หลายตัวไปเรื่อย ๆ แล้วพบว่าต้องแก้ commit แรก แค่แก้ commit นั้นแล้วบันทึก commit อื่นทั้งหมดก็จะถูก rebase ตามให้เป็นสถานะล่าสุดเอง หลังจากทำ PR ไปแล้ว ถ้าอยากแก้ commit ที่ 3 ก็แค่แก้ commit นั้นแล้ว push ใหม่ได้เลย การทำแบบนี้ด้วย Git ตรง ๆ นั้นยากมาก เพื่อนร่วมงานของผมชอบ PR ที่แยกเป็นหลาย commit มาก

    • ผมก็คิดคล้ายกัน โดยรวมผมรู้สึกว่า Git UI ยังไม่ค่อยดีนัก เลยยินดีจะลองเชื่อใจและใช้ jj อยู่บ้าง แต่ถ้ามีการสาธิตให้เห็นชัด ๆ ว่า “ทำไมมันถึงง่ายกว่า ทรงพลังกว่า หรือสะดวกกว่า” ก็น่าจะดีกว่านี้มาก

    • ตัวอย่างหนึ่งคือ คุณสามารถลงทะเบียน merge conflict ไว้เป็นรายการหนึ่งแล้วค่อยกลับมาจัดการทีหลังได้: https://jj-vcs.github.io/jj/latest/conflicts/

  • ช่วงหลังผมลองกลับมาใช้ JJ อีกครั้งแล้วพบว่ามันดีขึ้นมาก เลยใช้อย่างมีความสุข ตอนที่ลองช่วงแรก ๆ มันยังมีเหลี่ยมคมให้สะดุดเยอะจนรู้สึกหนักใจ แต่ผมคิดว่า JJ เป็นส่วนหนึ่งของ “คลื่นลูกใหม่” ของ tooling ที่ยอดเยี่ยมในช่วงหลัง ผมยังเขียนเรื่องนี้ไว้ในบล็อกด้วย: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/

    • บทความดีมาก ผมคิดว่ามาตรฐานของ developer tooling ในช่วงไม่กี่ปีมานี้สูงขึ้นมากจริง ๆ Rust ก็เป็นส่วนหนึ่งของการเปลี่ยนแปลงนั้นด้วย

    • ดีใจที่คุณใช้และชอบ mise เหมือนกัน mise, jj (รวมถึง jjui TUI ที่เท่มาก), และ uv สำหรับ Python ล้วนเปลี่ยนเกมได้หมด ผมว่าเครื่องมือพวกนี้งดงามจริง ๆ

    • ผมอยากเพิ่ม nushell เข้าไปในรายการนี้ด้วย

    • Bun ก็เป็นผู้นำของการปฏิวัติ tooling นี้เหมือนกัน

  • งานยอดเยี่ยม! ผมใช้ Jujutsu อย่างเดียวมาเกือบ 5 เดือนแล้วจนแทนที่ git ไปหมด ในช่วงนั้นจริง ๆ แล้วผมเรียก Git แค่ 52 ครั้ง (ในนั้น 11 ครั้งเป็น --help) แต่ใช้ Jujutsu ไปถึง 582 ครั้ง โดยไม่ต้องฝืนให้เข้ากับเวิร์กโฟลว์แบบใดแบบหนึ่ง Jujutsu ยืดหยุ่นพอจะรองรับแทบทุกเวิร์กโฟลว์ ต่อให้ใช้มันเหมือน git คุณก็ยังย้าย commit กับ branch ไปมาได้อย่างอิสระ (ไม่ต้อง stash) และ rebase ได้ง่าย (คนที่เก่ง git อาจคุ้นอยู่แล้ว แต่การทำได้ตรง ๆ โดยไม่ต้องพึ่งเครื่องมือ git ของ VSCode นี่น่าขอบคุณมาก) ทำให้โฟกัสกับงานได้โดยไม่ต้องรับภาระจุกจิกจาก VCS สิ่งที่ควรรู้คือ ประวัติการทำงานยังคงอยู่ใน git repo ตามเดิม จึงเข้ากันได้กับเครื่องมือ git อื่น ๆ ด้วย หมายความว่าเพื่อนร่วมงานไม่ต้องเปลี่ยน VCS แต่ผมเลือกใช้ตัวอื่นได้ ยังมีจุดที่ขาดอยู่บ้างแถว ๆ tag, submodule, และ LFS แต่ก็ยังคุ้มค่าที่จะลองมาก

    • ผมสงสัยว่าอะไรคือทางเทียบเท่าของ git branch --set-upstream-to ใน jj

    • ลองใช้ jjui แล้วคุณแทบจะไม่ต้องแตะคำสั่ง jj อีกเลย น่าทึ่งจริง ๆ

  • Jujutsu ดีจริง ๆ ผมลองใช้เมื่อหลายเดือนก่อนและก็เขียนเกี่ยวกับมันไว้สองสามชิ้น (โพสต์นี้) จากนั้นก็ใช้อยู่ต่อเนื่อง โดยรวมแล้วมันเป็นประสบการณ์ที่ “สอดคล้องกัน” มาก จริง ๆ ผมก็เป็นคนที่ใช้ git ได้ไม่มีปัญหา แต่ jj ทำให้ทุกอย่างหมุนอยู่บนหลักพื้นฐานไม่กี่ข้อ แล้วคุณก็เอามาประกอบกันตามต้องการเพื่อแก้ไขประวัติการทำงานที่ซับซ้อนได้ง่ายมาก เดิมทีผมทำงานแบบ “เน้น stash” แต่ jj สบายกว่ามากเพราะมีการติดตามการเปลี่ยนแปลงอัตโนมัติ ย้ายการเปลี่ยนแปลงไปมาได้อย่างอิสระ ฯลฯ การ rebase และแก้ conflict ก็ทำได้ดีกว่ามาก (โดยเฉพาะกับเวิร์กโฟลว์สไตล์ stash) แนะนำมาก และต้นทุนในการย้ายมาก็ต่ำมาก

  • ส่วนตัวผมไม่ค่อยชอบแนวทางที่เพิ่ม layer ใหม่ทับบน git ผมเข้าใจว่าการฝ่า hegemony ของ git นั้นยาก แต่คิดว่าการสร้างบนฐานใหม่ทั้งหมดน่าจะทรงพลังกว่าและเป็นอิสระกว่ามาก

  • ผมใช้ jj อยู่ประมาณเดือนหนึ่งแล้วต้องกลับไปใช้ git เพราะโปรเจ็กต์เฉพาะตัวหนึ่งในบริษัท ผมชอบ jj มากจริง ๆ แต่ก็แค่นั้น อย่างไรก็ตาม กลับไปใช้ git ได้ไม่กี่ชั่วโมง ผมก็คิดถึงความสะดวกของ jj อย่างแรงแล้ว: https://blog.nawaz.org/posts/2025/Aug/the-jujutsu-effect/

    • สงสัยว่า “แต่ก็แค่นั้น” หมายถึงอะไรแน่

    • หมายถึงกว่าจะรู้คุณค่าก็ตอนเสียมันไปแล้ว

  • ผมอยากอ่านอะไรในหัวข้อ “Jutustsu for Git experts” มากกว่านี้ เช่น การ commit conflict จะทำให้ git rerere ของผมพังไหม หรือใน git ผมชอบทำงานแบบ git add -p เพื่อ stage แค่บางส่วนของ patch เลยอยากรู้ว่าใน jj มีวิธีทำ patch set สองขั้นแบบสะดวก ๆ ไหม ผมอยากหลีกเลี่ยง timestamp เพี้ยนหรือ build system rebuild โดยไม่จำเป็น

    • ขอตอบด้วยเวิร์กโฟลว์ที่ใช้กันมากที่สุดใน jj (“squash workflow”) คุณแก้ไขอย่างอิสระใน top commit ซึ่งเป็น working directory แล้วพออยาก “stage” ก็ squash down ลงไปที่ commit ข้างล่าง (คือด้านล่างหนึ่งขั้น) ได้เลย จะเอาทั้งหมดหรือเลือกเฉพาะบางส่วนด้วย -i ก็ได้ และยังมี squash --into ให้ระบุ commit อื่นเพื่อ squash ไปยังตำแหน่งที่ต้องการด้วย

      1. jj ไม่ได้ใช้ git rerere ดังนั้นคำถามนี้จึงคลาดเคลื่อนไปนิด 2. @ คือ workspace และ @- คือ commit ที่คุณกำลังทำงานอยู่ คุณสามารถใช้ jj squash -i เพื่อย้อน diff บางส่วนที่ต้องการกลับไปที่ @ แบบ interactive ได้

    • แม้ผมจะเห็นด้วยว่า “การแบ่ง stage/unstage ไม่จำเป็น” แต่ก็ยังรู้สึกแปลกที่หลายคนบอกว่า “การ stage เฉพาะส่วนที่ชอบใน patch นั้นดีมาก” คุณพอจะทำอะไรคล้าย ๆ กันได้โดยใช้ git worktree, git diff, vi, git apply โดยไม่ต้อง stage แต่ยุ่งยากมาก ส่วน mercurial 7.1 ก็ยังไม่มี interactive add อยู่ดี จึงแทบไม่มีทางเลือกนอกจากใช้วิธีอ้อมผ่าน worktree

  • ช่วงหลังผมเห็นคนพูดถึง Jujutsu บ่อยขึ้น แต่ยังไม่ได้ลงรายละเอียดถึงระดับเวิร์กโฟลว์ อยากรู้ว่า Jujutsu มีข้อได้เปรียบชัดเจนเหนือ Emacs Magit หรือเปล่า Git UI ที่ผมเคยใช้ส่วนใหญ่ยังไม่ดีนัก แต่ Magit ทำให้ประสิทธิภาพการใช้ git ของผมดีขึ้นมากและทำให้สัมผัสได้ถึง “มนตร์” ของ git เลยสงสัยว่า Jujutsu พยายามจะมาแข่งกับประสบการณ์นี้ หรือแค่อยากเป็นทางเลือกแทน Git UI เดิม ๆ ที่ยังขาดอยู่กันแน่

    • Jujutsu ไม่ใช่แค่ Git UI และจริง ๆ แล้วในฐานะ Git UI มันค่อนข้างอ่อนด้วยซ้ำ (ยังรองรับ tag, submodule ฯลฯ ไม่ดี) มันคือ VCS ใหม่ทั้งตัว แต่ใช้ git เป็น backend ถ้า git เคยนำเสนอ “cheap branch” เมื่อเทียบกับ SVN, JJ ก็เสนอ “cheap rebase” conflict จะไม่มาขัดจังหวะงานทั้งหมด และการ rebase หรือจัดโครงสร้าง commit ก็สะดวกมาก ถ้าคุณเคยใช้ stacked diffs มาก่อนจะรู้สึกคุ้นเคย และ stacked diff PR ใน jj ก็ทำได้แทบไม่ต้องออกแรง

    • ถ้าคุณเป็นคนที่ใช้ Magit หนักอยู่แล้ว แนวคิดพื้นฐานของ jj ก็น่าจะดึงดูดใจคุณเหมือนกัน jj ทำสิ่งที่เคยคิดว่าเป็นไปไม่ได้ในด้าน commit acrobatics ได้ (เช่น rebase ใบ 2 ตัวใน 5-way octopus merge ทั้งที่ conflict ยังไม่ถูกแก้) นี่เป็นเทคนิคที่ผมสร้างขึ้นและเรียกว่า “Mega Merge” Magit กับ jj มีอะไรคล้ายกันอยู่ตรงที่ “มนตร์ของ git” จริง ๆ แล้วก็มาจาก “ภาษาการออกแบบ” ของเครื่องมือ git เป็นแค่ชั้นเก็บข้อมูลทางกายภาพของทั้ง Magit และ jj แต่ในด้านอัลกอริทึม UX และแนวคิดนั้นต่างกันมาก ผู้ใช้ Magit มักจะช็อกกับ jj น้อยกว่า แต่ผู้ใช้ Git command line ระดับสูงกลับย้ายมา jj ได้ง่ายมาก และมักกลายเป็นผู้เผยแพร่ตัวแรงด้วย เพราะพวกเขาเข้าใจพลังของเครื่องมือที่เชี่ยวชาญการจัดการ commit graph ดีกว่าใคร อนึ่ง ผมเป็นหนึ่งใน maintainer ของ jj และคิดว่ามันเป็นเครื่องมือที่ออกแบบมาดีมาก อยากแนะนำให้ลองใช้สักสองสามวันโดยไม่พึ่ง Magit ดู

    • มีลิงก์เกี่ยวข้องอยู่ตรงนี้ บทความที่อธิบายเวิร์กโฟลว์ Megamerge ได้ดี: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/, https://ofcr.se/jujutsu-merge-workflow, และ TUI ระดับยอดเยี่ยมที่ครอบ jj cli ไว้: https://github.com/idursun/jjui

    • ผมสงสัยว่า “แนวคิดศูนย์กลาง” ของ Jujutsu คืออะไร เมื่อเทียบกับการที่ Git เป็นมาตรฐานอุตสาหกรรมแล้ว ยังไม่ค่อยเห็นเหตุผลที่หนักแน่นพอให้ต้องใช้ Jujutsu แม้จะคิดว่าแนวคิดมันน่าสนใจ แต่ถ้ามีการสื่อสารเชิงการตลาดที่ชัดเจนกว่านี้ก็น่าจะช่วยให้คนหยิบไปใช้มากขึ้น จุดอ่อนใหญ่ที่สุดของ Git คือมันไม่เป็นมิตรกับคนนอกเอามาก ๆ (ศัพท์เฉพาะ การค้นหาความสามารถต่าง ๆ ที่ยาก GUI frontend ที่มีไม่มาก ฯลฯ) ดังนั้นผมคิดว่า VCS ที่เป็นมิตรกับมือใหม่มีศักยภาพมาก

    • ผมย้ายจาก Magit ไป jujutsu สิ่งที่เปลี่ยนไปคือการซ้อน PR ง่ายขึ้นมาก และผมเริ่มมีนิสัยแยกการเปลี่ยนแปลงให้เล็กลง จนเกณฑ์ว่าอะไร “คุ้มจะส่ง” เข้มงวดขึ้น โดยรวมเป็นประสบการณ์เชิงบวก แต่ถ้า Magit เข้ากับวิธีทำงานของคุณดีอยู่แล้ว ก็ไม่ได้มีข้อได้เปรียบพิเศษอะไร ถึงอย่างนั้นก็ยังใช้ jj ใน Emacs ได้สบายด้วย https://github.com/bolivier/jj-mode.el

  • อ่านแล้วน่าสนใจ แม้ผมจะใช้ชีวิตออนไลน์เยอะ แต่เพิ่งเคยได้ยินชื่อ Jujutsu ก็ครั้งนี้เอง ผมชอบแนวคิดที่ใช้ Git เป็น backend แล้วมอบ VCS ที่ดีกว่าให้ หนึ่งในเหตุผลคือมันยังสำรองและแชร์ผ่าน Github-Gitlab ได้อยู่ Fossil กับ Bitkeeper ก็มีเสน่ห์ของมัน แต่ยังไม่ได้ “ดีกว่าแบบชัดพอ” ที่จะเอาชนะแรงเครือข่ายของ git ได้ ผมคงต้องลองจับ Jujutsu ดูสักหน่อย ไม่รู้ว่าจะใช้ต่อไหม แต่ก็หวังว่ามันจะดีกว่าที่คิดไว้