Jujutsu cho mọi người

 (jj-for-everyone.github.io)
2 điểm bởi GN⁺ 2025-09-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Tài liệu này là một hướng dẫn nhập môn dạy Jujutsu (VCS) theo từng cấp độ để ngay cả người chưa có kinh nghiệm với Git cũng có thể làm theo từng bước
  • Hướng dẫn giả định có sử dụng terminal, nhưng cũng bao quát từ kiến thức terminal cơ bản; các lệnh chính được giải thích chủ yếu theo Linux/macOS, và người dùng Windows được khuyến nghị dùng WSL
  • Lộ trình học được thiết kế để xây nền cơ bản · cộng tác · xử lý sự cố ở cấp độ 1~3, rồi mở rộng lên rewrite lịch sử · workflow nâng cao ở các cấp cao hơn
  • Để phòng trường hợp trạng thái bị rối trong lúc học, tài liệu cung cấp môi trường học có thể tái lập với script reset giúp quay lại điểm bắt đầu của từng chương
  • Về câu hỏi vì sao dùng Jujutsu thay vì Git, tài liệu đưa ra các lý do gồm tương thích với Git, giảm độ khó khi học, và tính năng nâng cao, đồng thời đang được cập nhật theo Jujutsu 0.32 mới nhất

Giới thiệu (Introduction)

  • Hướng dẫn này là tài liệu nhập môn dành cho người dùng lần đầu sử dụng Jujutsu
  • Cung cấp nội dung lấy người mới bắt đầu làm trung tâm để bù đắp hạn chế của các tài liệu Jujutsu hiện có vốn tập trung vào người dùng Git đã thành thạo chuyển sang
  • Việc sử dụng terminal là mặc định, đồng thời có chương về cách dùng terminal cơ bản; người dùng Windows được khuyến nghị dùng WSL

Cách đọc hướng dẫn này (How to read this tutorial)

  • Nội dung được tổ chức theo từng cấp độ, và thiết kế học tập là sau khi hoàn thành mỗi cấp thì hãy thực hành thật sự rồi mới sang cấp tiếp theo
  • Nếu mục tiêu là cộng tác, tài liệu khuyến nghị học liên tiếp cấp 1 và 2
  • Tổng quan các cấp độ
    • Cấp 1: Cung cấp bộ khởi đầu tối thiểu cần cho công việc cá nhân, phù hợp với mức sinh viên tự quản lý bài tập một mình
    • Cấp 2: Bộ tối thiểu cho cộng tác, cần cho dự án nhóm sinh viên và lập trình viên trong công việc thực tế
    • Cấp 3: Nền tảng xử lý sự cố như giải quyết xung đột, khôi phục, tương ứng với mức thành thạo của một lập trình viên trung bình
    • Cấp 4: Xây dựng lịch sử gọn gàng bằng rewrite lịch sử, cần thiết để đáp ứng tiêu chuẩn chất lượng của một số dự án
    • Cấp 5: Tăng tốc năng suất · workflow nâng cao · CLI hiếm dùng · lý thuyết, cấp độ master của Jujutsu
    • Cấp 6: Các chủ đề theo tình huống như tag · submodule · workspace, khuyến nghị tra cứu khi cần

Phím tắt (Keyboard shortcuts)

  • Hỗ trợ di chuyển giữa các chương bằng phím mũi tên trái/phải
  • Hỗ trợ tìm kiếm trong sách bằng S hoặc /
  • Hỗ trợ hiện trợ giúp bằng ? và ẩn bằng Esc

Đặt lại tiến độ (Reset your progress)

  • Vì trạng thái của kho ví dụ liên kết với chương tiếp theo, nên nếu mất trạng thái thì bạn có thể không thể tiếp tục
  • Để giải quyết việc này, tài liệu cung cấp script reset.sh giúp khôi phục về điểm bắt đầu của chương
  • Phần đầu của mỗi chương có kèm lệnh reset chính xác, nên có thể tái lập chỉ bằng copy-paste
  • Khuyến nghị xem trước nội dung script trước khi chạy; thực tế đây chỉ là thao tác đơn giản ở mức tập hợp các lệnh thủ công
  • Các đặc điểm chính của script
    • Chặn ảnh hưởng từ cấu hình người dùng bằng JJ_CONFIG=/dev/null
    • Tạo repo ví dụ, tích hợp colocate Git, thiết lập thông tin người dùng, rồi tái dựng kịch bản liên hoàn như commit/push/fetch/rebase
    • Thiết kế phân nhánh để nhận từ khóa chương làm đối số và thoát thành công tại đúng điểm tương ứng

Luôn cập nhật (Stay up to date)

  • Cả hướng dẫn lẫn Jujutsu đều đang liên tục phát triển, và bạn có thể nhận thông báo về các thay đổi lớn bằng cách theo dõi Releases của kho hướng dẫn
  • Hướng dẫn này ghi rõ đang cập nhật theo Jujutsu 0.32 (tháng 8 năm 2025)
  • Cung cấp hướng dẫn thiết lập thông báo cập nhật trên GitHub qua Watch → Custom → Releases

Kiểm soát phiên bản là gì và vì sao cần dùng? (What is version control and why use it?)

  • Đây là phương tiện quản lý quá trình tích lũy công việc theo từng bước, áp dụng không chỉ cho phần mềm mà cả soạn thảo tài liệu như Typst
  • Nó hỗ trợ an toàn việc quay lại trạng thái trước đó và nhiều người cùng làm việc đồng thời
  • Khi cần công cụ kiểm soát sắc bén hơn so với sao lưu thông thường hay trình soạn thảo cộng tác, Jujutsu là lựa chọn phù hợp

Vì sao là Jujutsu? (Why Jujutsu instead of Git?)

  • Tương thích với Git: Có thể tương tác không mất mát với các kho Git hiện có, và tiếp tục tận dụng nguyên vẹn phần lớn công cụ tích hợp Git
  • Dễ học hơn: So với UI phức tạp, thiếu trực quan của Git, Jujutsu cung cấp cùng tính năng với độ phức tạp thấp hơn
  • Tính năng mạnh hơn: Tách biệt với chuyện dễ học, nó còn cung cấp nhiều tính năng cho power user, đảm bảo khả năng mở rộng workflow
  • Nhược điểm và điểm cần cân nhắc
    • Khi trao đổi vẫn có gánh nặng ánh xạ khái niệm với văn hóa lấy thuật ngữ Git làm trung tâm; có thể giảm bớt bằng cách thuyết phục đồng nghiệp
    • Vì còn khá mới nên có trường hợp thiếu một số tính năng của Git; khi cần vẫn có thể fallback sang dùng Git trực tiếp
    • CLI vẫn đang trong quá trình ổn định, nên một số lệnh có thể thay đổi; khuyến nghị theo dõi release của hướng dẫn để bám sát thay đổi

Tiến trình học (Completed & Next)

  • Hiện tài liệu được tổ chức chủ yếu quanh cấp 1~3 để người học nắm vững luồng bài tập thực chiến (cài đặt → khởi tạo → log/commit → remote/push·clone → branch/merge → rebase → điều hướng → hoàn tác/khôi phục → giải quyết xung đột → dọn dẹp)
  • Đồng thời đề xuất chiến lược nâng cao dần bằng cách học thêm rewrite · workflow nâng cao · các chủ đề ít gặp ở các cấp cao hơn

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-09-01
Ý kiến trên Hacker News

  • Có cảm giác như tôi đã thấy hàng chục bài chỉ toàn khen jj. Hướng dẫn này cũng tương tự, nhưng giờ tôi đã đọc đủ về điểm tốt rồi nên quan tâm hơn đến nhược điểm và những chỗ bất tiện. Khi dùng jj, tôi thấy nó có cả ưu lẫn nhược. Tôi thường dùng quy trình làm việc chia sẻ branch với đồng nghiệp rồi tiếp tục chồng thêm commit lên đó, nhưng với jj thì vì không có branch có tên nên dùng bất tiện hơn git (dùng alias tug cũng vậy). Mục “Tracking remote bookmarks” trong bài hướng dẫn với tôi vẫn trông khá bất tiện. Một điểm nữa là jj không dùng được light clone như git clone --filter=blob:none của git, nên tôi muốn biết điều này đã được sửa chưa

    • jj có branch có tên, chỉ là trong jj chúng được gọi là “bookmarks”. Nếu theo dõi remote bookmark thì jj git fetch sẽ đồng bộ bản local với remote

    • Một trong những điều khiến tôi vất vả là jj đôi khi có vẻ làm mất thay đổi của tôi một cách ngẫu nhiên. Tôi làm việc trong Cursor và không hề mutating repo bằng jj (chỉ dùng kiểu jj status, jj log), nhưng đến lúc sau thì có khi thay đổi của tôi biến mất, và thỉnh thoảng còn hiện thông báo "stale workspace". Tôi không rõ là do IDE hay do monorepo quá lớn, nhưng thật sự rất đau đầu. Dù vậy, tôi vẫn rất thích độ linh hoạt của jj

    • Có một cuộc thảo luận ở https://github.com/jj-vcs/jj/discussions/3549 về việc làm cho workflow tug đơn giản hơn một chút

    • Nói jj không có branch có tên là không đúng. Bạn chỉ cần chỉ định thủ công như jj branch set -r@ XYZ, hơi bất tiện một chút nhưng chỉ cần làm một lần khi push. Hoặc cũng có thể di chuyển branch bằng jj git push --named XYZ=@

    • Việc jj chưa hỗ trợ light clone (git clone --filter=blob:none) vẫn chưa được giải quyết

  • Bài viết nói “Jujutsu mạnh hơn Git”, nhưng lại không giải thích cụ thể mạnh hơn ở điểm nào, nên tôi thắc mắc rốt cuộc vì sao phải dùng nó. Câu này có vẻ chỉ là lời quảng bá chung chung

    • Tôi là tác giả bài hướng dẫn. Vì đối tượng là người mới nên việc so sánh chi tiết với Git không phù hợp. Sự phức tạp của Git UI thường được biện minh bằng cái gọi là “mạnh mẽ”, nên tôi chỉ muốn nói thêm để người dùng biết rằng Jujutsu không đánh đổi tính năng chỉ để dễ học hơn

    • Ví dụ, bạn tạo một branch mới từ Main và định sau này gửi thành PR. Bạn chồng nhiều commit lên, rồi nhận ra cần sửa commit số 1. Chỉ cần sửa commit 1 rồi lưu lại, tất cả các commit khác sẽ tự động rebase lên trạng thái mới nhất. Sau cả khi đã gửi PR, nếu muốn sửa commit số 3 thì chỉ cần chỉnh đúng commit đó rồi push là xong. Tự làm kiểu này trực tiếp bằng Git thực sự rất khó. Đồng nghiệp của tôi rất thích các PR được tách thành nhiều commit

    • Tôi cũng nghĩ tương tự. Nhìn chung tôi thấy các Git UI còn nhiều hạn chế nên sẵn sàng tin tưởng và dùng jj ở một mức độ nào đó. Nhưng sẽ tốt hơn nếu có phần trình diễn cụ thể về “vì sao nó dễ hơn, mạnh hơn hoặc tiện hơn”

    • Một ví dụ là có thể ghi nhận merge conflict thành một mục riêng rồi xử lý sau: https://jj-vcs.github.io/jj/latest/conflicts/

  • Gần đây tôi thử lại JJ và thấy nó đã tốt lên rất nhiều nên đang dùng khá vui. Lúc mới thử thời gian đầu thì có khá nhiều góc cạnh sắc bén khiến tôi ngại dùng, nhưng tôi nghĩ JJ là một phần của “làn sóng mới” đầy ấn tượng trong tooling xuất hiện gần đây. Tôi cũng có viết một bài blog liên quan: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/

    • Bài viết hay đấy. Tôi nghĩ vài năm gần đây tiêu chuẩn cho tooling phát triển phần mềm thực sự đã tăng lên rất nhiều. Rust cũng là một phần của sự thay đổi đó

    • Rất vui khi thấy bạn cũng dùng và thích mise. mise, jj (và jjui TUI cực kỳ tuyệt), cùng với uv cho Python đều mang tính cách mạng. Tôi thấy những công cụ như vậy thật sự rất đẹp

    • Tôi cũng rất muốn thêm nushell vào danh sách này

    • Bun cũng đang đi đầu trong cuộc đổi mới tooling này

  • Làm rất tuyệt! Tôi gần như đã dùng riêng Jujutsu suốt 5 tháng và thay thế hoàn toàn git. Thực tế trong thời gian đó tôi chỉ chạy Git 52 lần (trong đó 11 lần là --help), còn Jujutsu thì dùng tới 582 lần. Không cần phải ép bản thân theo một workflow cụ thể nào, Jujutsu đủ linh hoạt để hỗ trợ gần như mọi workflow. Ngay cả khi dùng nó theo kiểu git, bạn vẫn có thể di chuyển commit và branch rất tự do (không cần stash), có thể rebase dễ dàng (có lẽ dân git chuyên sẽ thấy quen, nhưng việc làm trực tiếp không cần dựa vào công cụ git của VSCode thật sự rất đáng quý), và có thể tập trung vào công việc mà không phải gánh những phiền toái thường thấy từ VCS. Điều cần lưu ý là lịch sử công việc vẫn được lưu trong repo git như cũ nên vẫn tương thích với các công cụ git khác. Nói cách khác, tôi có thể dùng thứ khác mà đồng nghiệp không cần đổi VCS. Có hơi tiếc ở phần tag, submodule và LFS, nhưng vẫn hoàn toàn đáng để thử

    • Tôi tò mò không biết phương án thay thế trong jj cho git branch --set-upstream-to là gì

    • Dùng jjui rồi thì gần như sau này bạn sẽ không còn phải chạm vào lệnh jj nữa. Thật sự đáng kinh ngạc

  • Jujutsu thật sự khá ổn. Tôi đã thử nó vài tháng trước và cũng viết mấy bài về nó (bài này), rồi từ đó đến nay vẫn dùng liên tục. Trải nghiệm tổng thể rất “nhất quán”. Thật ra tôi vốn là người dùng git không có vấn đề gì, nhưng jj khiến mọi thứ vận hành theo vài nguyên lý cơ bản và bạn có thể kết hợp chúng theo ý muốn để thay đổi lịch sử phức tạp một cách dễ dàng. Trước đây tôi thường làm việc theo kiểu “stash-heavy”, nhưng jj dễ chịu hơn git rất nhiều nhờ tự động theo dõi thay đổi, di chuyển thay đổi tự do, v.v. Rebase và xử lý xung đột cũng tốt hơn nhiều (đặc biệt với workflow kiểu stash). Tôi rất khuyến khích, và công sức để chuyển sang cũng rất nhỏ

  • Cá nhân tôi không thích cách tiếp cận thêm một lớp mới lên trên git. Tôi hiểu là rất khó vượt qua thế thống trị của git, nhưng tôi nghĩ xây dựng trên một nền tảng hoàn toàn mới sẽ mạnh hơn và tự do hơn nhiều

  • Tôi dùng jj khoảng một tháng rồi quay lại git vì một dự án cụ thể ở công ty. Tôi thực sự thích jj, nhưng lúc đó cũng chưa đến mức hơn thế. Thế mà chỉ vài tiếng sau khi quay lại git, tôi đã nhớ da diết sự tiện lợi của jj: https://blog.nawaz.org/posts/2025/Aug/the-jujutsu-effect/

    • Tôi tò mò “chưa đến mức hơn thế” chính xác là có ý gì

    • Ý là chỉ khi mất đi rồi mới nhận ra giá trị thật của nó

  • Tôi muốn đọc thêm về chủ đề “Jutustsu for Git experts”. Ví dụ, tôi muốn biết việc commit conflict có làm hỏng git rerere của tôi không, hoặc trong git tôi thích dùng git add -p để chỉ stage một phần patch khi làm việc, vậy trong jj có cách nào tiện để triển khai patch set hai giai đoạn không. Tôi muốn tránh làm hỏng timestamp hoặc gây ra các lần rebuild vô nghĩa của build system

    • Tôi trả lời theo workflow phổ biến nhất trong jj (“squash workflow”). Bạn thay đổi tự do ở top commit là working directory, và khi muốn “stage” thì chỉ cần squash down xuống commit bên dưới (tức commit thấp hơn một bậc), có thể là toàn bộ thay đổi hoặc chỉ một phần với -i. Ngoài ra còn có squash --into để chỉ định commit khác và squash vào đúng chỗ bạn muốn

      1. jj không dùng git rerere nên câu hỏi này hơi lệch hướng. 2. @ là workspace, còn @- là commit bạn đang làm việc. Với jj squash -i, bạn có thể tương tác để đưa một phần diff mong muốn trở lại @

    • Dù tôi đồng ý rằng “không cần phân biệt stage/unstage”, tôi vẫn thấy thú vị khi có người nói “stage chỉ phần mình thích trong patch là cực kỳ hay”. Với tổ hợp git worktree, git diff, vi, git apply thì cũng có thể đạt hiệu ứng tương tự mà không cần staging, nhưng thật sự rất phiền. Ngay cả mercurial 7.1 vẫn chưa có interactive add, nên ngoài cách lách bằng worktree thì không có lựa chọn nào khác

  • Gần đây tôi có thấy nói về Jujutsu, nhưng chưa đi sâu đến mức workflow cụ thể. Tôi tò mò không biết Jujutsu có điểm gì vượt trội rõ rệt so với Emacs Magit không. Hầu hết Git UI tôi từng dùng đều khá thiếu sót, nhưng Magit đã giúp năng suất git của tôi tăng mạnh và khiến tôi cảm nhận được “ma thuật” của git. Không rõ Jujutsu đang muốn cạnh tranh với chính trải nghiệm đó, hay mục tiêu là làm phương án thay thế cho các Git UI hiện tại (vốn thật sự còn thiếu)

    • Jujutsu không phải chỉ là Git UI; ngược lại, nếu xét như Git UI thì nó còn khá yếu (thiếu hỗ trợ tag, submodule, v.v.). Nó là một VCS hoàn toàn mới nhưng dùng git làm backend. Nếu git mang lại “cheap branch” so với SVN, thì JJ mang lại “cheap rebase”. Conflict không còn chặn toàn bộ công việc, còn rebase, quản lý cấu trúc commit, v.v. thì cực kỳ thuận tiện. Nếu bạn từng dùng stacked diffs thì sẽ thấy quen, và stacked diff PR trong jj gần như làm được mà không tốn công

    • Nếu bạn đã dùng Magit nhiều rồi thì các khái niệm nền tảng của jj cũng sẽ hấp dẫn bạn. jj cho phép những màn acrobatics với commit mà trước đây người ta nghĩ là bất khả thi (ví dụ: rebase 2 leaf trong một 5-way octopus merge khi conflict vẫn chưa được giải quyết). Đây cũng là một kỹ thuật tôi tạo ra dưới tên “Mega Merge”. Magit và jj có điểm giống nhau ở chỗ tôi nghĩ “ma thuật của git” thực ra đến từ “ngôn ngữ thiết kế” của công cụ. Git chỉ là lớp lưu trữ vật lý chung cho cả Magit lẫn jj, còn khác biệt lớn nằm ở thuật toán, UX và khái niệm. Người dùng Magit thường ít bị sốc hơn khi chuyển sang jj, nhưng những người dùng Git CLI nâng cao lại chuyển sang jj cực kỳ dễ và thực tế còn trở thành những người truyền bá rất mạnh. Họ là những người hiểu rõ hơn ai hết sức mạnh của công cụ giỏi thao tác đồ thị commit. Nhân tiện, tôi là một trong các maintainer của jj, và tôi nghĩ đây là một công cụ được làm rất tốt. Rất đáng để thử dùng vài ngày mà không có Magit

    • Đây là vài liên kết liên quan. Bài giải thích rất rõ về workflow Megamerge: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/, https://ofcr.se/jujutsu-merge-workflow, và TUI hàng đầu bao quanh jj cli: https://github.com/idursun/jjui

    • Tôi tò mò “khái niệm trung tâm” của Jujutsu là gì. So với việc Git là chuẩn chung của ngành, tôi chưa thực sự cảm nhận được lý do đủ mạnh để phải dùng Jujutsu. Tôi thấy các ý tưởng của nó thú vị, nhưng có lẽ nếu có một góc nhìn marketing rõ ràng hơn thì khả năng ứng dụng sẽ cao hơn. Điểm yếu lớn nhất của Git là nó quá thiếu thân thiện với người ngoài cuộc (thuật ngữ, khó khám phá, thiếu GUI frontend tốt, v.v.), nên tôi nghĩ một VCS thân thiện với người mới có tiềm năng rất lớn

    • Tôi đã chuyển từ Magit sang jujutsu. Điều thay đổi là việc xếp chồng PR trở nên dễ hơn rất nhiều, và tôi cũng hình thành thói quen chia thay đổi thành các phần nhỏ hơn nên tiêu chuẩn “đủ đáng để gửi” trở nên khắt khe hơn. Nhìn chung là trải nghiệm tích cực, nhưng nếu Magit đã quá hợp với bạn thì không có lợi thế áp đảo nào. Dù vậy, nhờ https://github.com/bolivier/jj-mode.el mà trong Emacs vẫn có thể dùng jj khá ổn

  • Thấy khá thú vị. Dù hoạt động online khá nhiều nhưng đây là lần đầu tôi nghe về Jujutsu. Tôi thích ý tưởng dùng Git làm backend nhưng cung cấp một VCS tốt hơn. Một lý do là vẫn có thể backup/chia sẻ qua Github-Gitlab như trước. Fossil hay Bitkeeper cũng hấp dẫn, nhưng chưa “đủ” tốt hơn git để vượt qua hiệu ứng mạng lưới của git. Tôi sẽ thử nghịch Jujutsu xem sao. Không chắc có dùng lâu dài không, nhưng hy vọng nó sẽ tốt hơn tôi nghĩ