Hướng dẫn Jujutsu của Evan

• Đây là một hướng dẫn được xây dựng để những người đã có kinh nghiệm dùng Git có thể nhanh chóng nắm được hệ thống quản lý phiên bản Jujutsu (jj) vừa đơn giản vừa mạnh mẽ
• Trước khi bắt đầu học, với những độc giả muốn biết vì sao nên dùng Jujutsu, tác giả cung cấp riêng một bài giới thiệu về Jujutsu
• Tác giả cũng giới thiệu các tài liệu thay thế phù hợp với từng trình độ người đọc như sách nhập môn theo lối hội thoại, tài liệu chính thức chi tiết, hay tài liệu dành cho người mới hoàn toàn với quản lý phiên bản
• Evan Martin tự tay biên soạn để cân nhắc kỹ việc chọn chủ đề nào, lược bỏ nội dung nào và sắp xếp thứ tự ra sao
• Không dùng AI để viết nội dung chính, mà chỉ dùng AI để kiểm tra lỗi sau khi đã hoàn thành phần lớn bài viết

---

Đối tượng độc giả và lộ trình học

• Jujutsu là một hệ thống quản lý phiên bản vừa đơn giản vừa mạnh mẽ, và trong hướng dẫn này sẽ được viết là jj
• Nội dung được thiết kế cho độc giả đã quen với Git, với lộ trình học ngắn gọn tập trung vào phần cốt lõi
• Nếu muốn bắt đầu ngay, bạn có thể vào Bắt đầu hướng dẫn; nếu muốn tìm hiểu lý do sử dụng trước, hãy xem bài giới thiệu Jujutsu

Tài liệu thay thế theo từng nhóm độc giả

• Nếu cách tiếp cận của hướng dẫn này không phù hợp, bạn có thể chọn các tài liệu sau tùy theo kinh nghiệm và sở thích
  • Steve's Jujutsu tutorial: tài liệu nhập môn được khuyên dùng nhất, trình bày theo lối hội thoại
  • Jujutsu documentation: cung cấp hướng dẫn chính thức đi sâu vào chi tiết ngay từ đầu
  • Jujutsu for Everyone: dành cho độc giả chưa có kinh nghiệm quản lý phiên bản trước đó

Tự tay biên soạn và phạm vi sử dụng AI

• Toàn bộ văn bản do Evan Martin trực tiếp viết, con người đã cân nhắc cẩn thận việc nên đưa vào hay lược bỏ điều gì cũng như sắp xếp theo thứ tự nào
• Không dùng AI để viết nội dung chính, mà chỉ dùng sau khi đã viết gần xong để kiểm tra lỗi

[GN⁺]

Ý kiến trên Lobste.rs

• Thành thật mà nói bằng chính uy tín của mình, tôi đã thử dùng jj khoảng một tuần nhưng cuối cùng lại phải nhờ LLM giúp để giảm bớt nỗi đau khi thao tác trực tiếp với Git, và tôi cũng không cảm thấy nó đủ sức thay thế hoàn toàn quy trình làm việc hiện tại
  Bình thường tôi chỉ dùng git checkout, git add, git commit, git push, và hầu như không gặp các vấn đề như index, stash, nhiều kiểu reset, rebase đang dang dở hay undo thiếu nhất quán như trong các bài quảng bá nói tới, cũng không mấy khi dùng monorepo
  Tôi tò mò đối tượng chính của Jujutsu là ai, và mọi người đã mất bao lâu để dùng jj thành thạo; lần tới có lẽ tôi cũng nên đầu tư ít nhất chừng ấy thời gian

  • Tôi tò mò không biết bạn nhờ LLM hỗ trợ cụ thể những việc gì
    Tôi cũng có xu hướng tránh mọi thứ ngoài các thao tác cơ bản trong Git, nên thay vì stash rồi đổi branch, tôi lại clone kho lưu trữ sang chỗ khác; thay vì chọn lọc chỉ commit các thay đổi liên quan, tôi dùng git add --all để commit hết hoặc hoàn tác thay đổi trong editor rồi commit xong lại áp dụng lại
    Ở chỗ làm tôi đã dùng Mercurial 7 năm nên có nền tảng giúp làm quen với jj dễ hơn, nhưng giờ đây việc sắp xếp lại commit và quản lý nhiều thay đổi đã trở nên đơn giản, đến mức tôi chủ động làm cả những việc phức tạp mà trước đây theo bản năng tôi sẽ tìm cách né tránh
  • Góc nhìn sẽ khác nhau tùy bạn dùng hệ thống quản lý phiên bản (VCS) để làm gì
    Nếu chỉ là phát triển code theo một đường thẳng rồi thỉnh thoảng lưu lại snapshot, thì các lệnh đó là đủ, và một VCS đầy đủ có khi còn quá mức cần thiết, Dropbox thôi cũng có thể đủ
    Với tôi, VCS là công cụ xây dựng tường thuật cho thấy tôi đã suy nghĩ về code và cấu trúc của nó như thế nào; độc giả chính là đồng nghiệp, còn độc giả phụ là chính tôi của 10 năm sau. jj giúp việc đó diễn ra với ít ma sát hơn rất nhiều
  • Nhờ LLM hỗ trợ cũng hoàn toàn ổn, và tôi cũng đã làm vậy cho đến khi quen được các lệnh cơ bản cần thiết
    Tôi đã đọc vài hướng dẫn từ đầu đến cuối để nắm nền tảng về thuật ngữ và tính năng, rồi dùng đều đặn trong dự án cá nhân vài ngày thì đã khá thành thạo các thao tác cơ bản, và cả cách nhìn của tôi về VCS cũng thay đổi
    Khi refactor hoặc phát triển tính năng lớn, tôi thường triển khai xong đến mục tiêu cuối cùng trước, rồi chia nhỏ thành các thay đổi như “sửa mọi cảnh báo eslint”, “refactor để expose hàm”, “chuyển nơi gọi A sang hàm mới”, “thêm tính năng mới” để dễ review và mỗi phần đều có lý do rõ ràng. jj split là công cụ hoàn hảo cho việc này, và chỉ riêng tính năng đó thôi cũng đã đủ lý do để dùng jj
    Ngược lại, git stash rất khó dùng khi phải xử lý nhiều stash, lại đầy những bẫy UX nguy hiểm có thể khiến bạn mất phần code đã lưu khi xảy ra xung đột. Việc áp dụng phản hồi PR vào commit thấp hơn rồi rebase các commit hoặc PR phía trên cũng gần như là cơn ác mộng, nhất là với PR xếp chồng, vì không có hiển thị tiến độ, dễ bị dừng giữa chừng và khó dựng lại stack. Vì vậy tôi vẫn dùng Graphite để quản lý PR xếp chồng
  • Lợi ích lớn nhất tôi nhận được từ jj là cách nó xử lý rebase
    Có một nghiên cứu sinh cao học ngành hóa hữu cơ đã phát triển branch phục vụ bài báo suốt 4 năm mà không merge hay rebase lần nào, khiến nó chậm hơn main tới hàng nghìn commit vào lúc cần phải merge trước buổi bảo vệ luận văn. Vì gần như commit nào cũng phát sinh xung đột, nếu dùng Git thì sẽ mất 1–2 tuần; nếu đến ngày thứ ba có bug khẩn cấp thì phải hủy rebase, sửa bug rồi quay lại làm lại từ đầu; và khi xong sau 3 tuần thì lại còn phải rebase lần nữa để khớp với main mới nhất
    Trong jj, xung đột merge là thực thể hạng nhất, nên có thể giải quyết khi có thời gian, và ngay cả giữa chừng bạn chuyển sang commit mới để sửa bug khẩn cấp thì cũng không mất tiến độ. Một lần rebase mà trong Git đáng lẽ mất cả tuần thì có thể xong trong một ngày, và có lần nó còn tìm ra 200 commit liên tiếp mà sau khi gộp vào cũng không tạo ra thay đổi gì, giúp vứt bỏ toàn bộ công việc xử lý xung đột hàng chục nghìn dòng suốt hai ngày chỉ trong chưa đầy một phút. Ngay cả trong lúc rebase, bạn vẫn có thể cập nhật main rồi chuyển branch đang làm việc lên trên main mới nhất

• Ngay cả với tôi, người đã quá quen với Git đến mức chỉ thỉnh thoảng mới phải tra lại lệnh, bài viết này là bài giới thiệu Jujutsu đầu tiên khiến tôi thực sự thấy hứng thú
  Các bài trước chủ yếu mở đầu bằng kiểu “bạn có thể thoát khỏi giao diện dòng lệnh Git khủng khiếp”, nhưng dù tôi hiểu Git có những điểm kỳ quặc và người khác gặp khó khăn ra sao, cách diễn đạt đó khiến tôi coi Jujutsu là thứ chẳng liên quan đến mình, như tiểu thuyết ngôn tình hay beef vindaloo vậy

  • Lý do khó diễn tả sự thú vị của jj là vì nhiều đặc tính ngầm mà người ta tưởng là hiển nhiên ở mọi VCS thực ra không phải vậy, và các thao tác nguyên tử thì đơn giản hơn rất nhiều
    Vì khó nghĩ ra câu quảng bá hay, nên rốt cuộc mọi lời giải thích đều bị chiếm bởi câu “nó không phải Git”, và bản thân tôi cũng không giỏi giải thích điều đó cho lắm
  • Trong Git, nếu dùng GUI Sublime Merge cùng vài lệnh tùy biến thì gần như có thể giải quyết được hầu hết các vấn đề được nói đến ở đây
    Khác với các Git GUI khác, nó bám sát các lệnh Git thật tối đa có thể, chỉ thay phần cú pháp khó hiểu bằng menu và nút bấm, đồng thời cũng không giấu lệnh tương ứng với từng thao tác mà ghi lại chúng ở thanh trạng thái. Nếu có Sublime JJ thì tôi sẽ chuyển ngay
  • Cách diễn đạt khiến tôi muốn thử jj là: Git nhưng luôn ở trạng thái interactive rebase