Jujutsu untuk Semua Orang

• Dokumen ini adalah tutorial pemula yang mengajarkan Jujutsu(VCS) dengan susunan level bertahap agar bisa diikuti bahkan tanpa pengalaman Git
• Mengasumsikan penggunaan terminal, tetapi juga membahas dasar-dasar terminal; perintah utama dijelaskan dengan fokus Linux/macOS, dan pengguna Windows disarankan menggunakan WSL
• Alur pembelajaran disusun agar fondasi dasar, kolaborasi, dan pemecahan masalah dibangun di level 1–3, lalu diperluas ke penulisan ulang riwayat dan workflow lanjutan di level yang lebih tinggi
• Untuk mengantisipasi kondisi saat status tutorial menjadi berantakan di tengah jalan, tersedia lingkungan belajar yang dapat direproduksi dengan skrip reset yang mengembalikan ke titik awal tiap bab
• Untuk menjawab mengapa memilih Jujutsu alih-alih Git, dokumen ini mengajukan alasan berupa kompatibilitas Git, kurva belajar yang lebih ringan, dan fitur lanjutan yang kuat, serta terus diperbarui berdasarkan Jujutsu 0.32

---

Pengantar(Introduction)

• Tutorial ini adalah materi pengenalan yang ditujukan bagi pengguna yang baru pertama kali memakai Jujutsu
• Menyediakan konten berfokus pada pemula untuk melengkapi keterbatasan materi Jujutsu yang ada, yang selama ini banyak berfokus pada peralihan pengguna Git berpengalaman
• Penggunaan terminal adalah dasar, dan tutorial ini mencakup bab tentang cara menggunakan terminal dasar; pengguna Windows disarankan memakai WSL

Cara membaca(How to read this tutorial)

• Isi disusun dalam unit level, dan rancangan belajarnya mendorong pembaca untuk benar-benar berlatih setelah menyelesaikan tiap level sebelum lanjut ke level berikutnya
• Jika tujuan Anda adalah kolaborasi, disarankan mengikuti level 1 dan 2 secara berurutan
• Ringkasan level
  • Level 1: Menyediakan set awal minimum yang dibutuhkan untuk pekerjaan pribadi, cocok untuk tingkat mahasiswa yang mengelola tugas sendiri
  • Level 2: Set minimum untuk kolaborasi, dibutuhkan untuk proyek tim mahasiswa dan developer profesional
  • Level 3: Dasar pemecahan masalah seperti penyelesaian konflik dan pemulihan, setara dengan tingkat kemahiran developer rata-rata
  • Level 4: Membangun riwayat yang rapi melalui history rewrite, diperlukan untuk memenuhi standar kualitas di beberapa proyek
  • Level 5: Pendorong produktivitas, workflow lanjutan, CLI yang jarang dipakai, dan teori, tahap master Jujutsu
  • Level 6: Topik berdasarkan situasi seperti tag, submodule, dan workspace, direkomendasikan untuk dirujuk saat diperlukan

Pintasan keyboard(Keyboard shortcuts)

• Mendukung navigasi antar bab dengan tombol panah kiri dan kanan
• Mendukung pencarian di dalam buku dengan S atau /
• Menampilkan bantuan dengan ? dan menyembunyikannya dengan Esc

Reset progres Anda(Reset your progress)

• Karena status repositori contoh terhubung dengan bab berikutnya, kehilangan status dapat menghambat kelanjutan tutorial
• Untuk mengatasinya, disediakan skrip reset.sh yang memulihkan ke titik awal bab
• Di awal tiap bab terdapat perintah reset yang tepat, sehingga lingkungan dapat direproduksi cukup dengan salin-tempel
• Disarankan untuk meninjau isi skrip sebelum menjalankannya; secara praktik, skrip ini hanya melakukan operasi sederhana setingkat kumpulan perintah manual
• Fitur utama skrip
  • JJ_CONFIG=/dev/null untuk mencegah pengaruh konfigurasi pengguna
  • Membuat repo contoh, integrasi Git colocate, pengaturan informasi pengguna, serta merekonstruksi skenario beruntun seperti commit/push/fetch/rebase
  • Dirancang bercabang agar menerima kata kunci tiap bab sebagai argumen dan berakhir sukses di titik tersebut

Tetap mutakhir(Stay up to date)

• Tutorial dan Jujutsu terus berkembang, dan Anda bisa menerima pemberitahuan perubahan besar dengan berlangganan Releases dari repositori tutorial
• Tutorial ini menyatakan dirinya mutakhir berdasarkan Jujutsu 0.32 (Agustus 2025)
• Juga disediakan panduan pengaturan notifikasi pembaruan di GitHub melalui Watch → Custom → Releases

Kebutuhan akan version control(What is version control and why use it?)

• Ini adalah sarana untuk mengelola akumulasi pekerjaan bertahap yang bisa diterapkan bukan hanya pada perangkat lunak, tetapi juga pada penulisan dokumen seperti Typst
• Mendukung kembali ke keadaan masa lalu dan pekerjaan simultan oleh banyak orang secara aman
• Dibanding backup biasa atau editor kolaboratif, Jujutsu cocok saat dibutuhkan alat kontrol yang lebih tajam

Mengapa Jujutsu(Why Jujutsu instead of Git?)

• Kompatibilitas Git: Dapat beroperasi bersama tanpa kehilangan apa pun dengan repositori Git yang ada, dan sebagian besar alat integrasi Git tetap bisa digunakan apa adanya
• Lebih mudah dipelajari: Dibanding UI Git yang rumit dan kurang intuitif, Jujutsu menyediakan fungsi yang sama dengan kompleksitas lebih rendah
• Fungsionalitas yang lebih kuat: Terlepas dari kemudahan belajar, Jujutsu menyediakan banyak fitur untuk power user yang menjamin skalabilitas workflow
• Kekurangan dan hal yang perlu dipertimbangkan
  • Dalam percakapan, ada beban untuk memetakan konsep ke budaya yang berpusat pada istilah Git; ini mungkin bisa dikurangi dengan meyakinkan rekan kerja
  • Karena relatif baru, ada kasus di mana sebagian fitur Git belum tersedia; bila perlu, Anda bisa fallback ke penggunaan Git secara langsung
  • CLI masih dalam proses stabilisasi, sehingga beberapa perintah dapat berubah; disarankan berlangganan rilis tutorial untuk mengikuti perubahan

Progres pembelajaran(Completed & Next)

• Saat ini materi berfokus pada level 1–3, agar pembaca menguasai alur tugas praktis seperti instalasi → inisialisasi → log/commit → remote/push·clone → branch/merge → rebase → navigasi → undo/pemulihan → penyelesaian konflik → perapian
• Di level yang lebih tinggi, diajukan strategi peningkatan bertahap dengan tambahan pembelajaran tentang rewrite, workflow lanjutan, dan topik yang lebih khusus

[GN⁺]

Komentar Hacker News

• Rasanya saya sudah melihat puluhan artikel yang memuji jj. Tutorial ini juga mirip, tetapi sekarang saya sudah cukup membaca hal-hal bagusnya, jadi saya lebih tertarik pada kekurangan dan hal-hal yang merepotkan. Saat saya mencoba jj, ada plus dan minusnya. Saya sering memakai alur kerja berbagi branch dengan rekan lalu terus menumpuk commit di situ, tetapi di jj ini lebih merepotkan daripada git karena tidak ada branch bernama sendiri (bahkan kalau memakai alias tug tetap begitu). Bagian “Tracking remote bookmarks” di tutorial juga masih terlihat merepotkan bagi saya. Hal lain yang tidak nyaman adalah jj tidak bisa memakai light clone seperti git clone --filter=blob:none milik git; saya penasaran apakah ini sudah diperbaiki

  • jj punya branch bernama, hanya saja di jj disebut “bookmarks”. Jika melacak remote bookmark, lokal akan tersinkron dengan remote lewat jj git fetch

  • Salah satu hal yang membuat saya kesulitan adalah jj kadang tampak kehilangan perubahan saya secara acak. Saya bekerja di Cursor dan tidak memutasi repo dengan jj (paling hanya jj status, jj log), tetapi ketika dicek belakangan kadang perubahan saya hilang, dan sesekali muncul pesan "stale workspace". Saya tidak tahu apakah ini karena IDE atau monorepo yang sangat besar, tetapi itu benar-benar menyiksa. Meski begitu, saya sangat suka fleksibilitas jj

  • Ada diskusi di https://github.com/jj-vcs/jj/discussions/3549 tentang cara membuat workflow tug sedikit lebih sederhana

  • Pernyataan bahwa jj tidak punya named branch itu keliru. Memang agak merepotkan karena harus ditetapkan manual seperti jj branch set -r@ XYZ, tetapi itu hanya perlu dilakukan sekali saat push. Atau bisa juga memindahkan branch dengan jj git push --named XYZ=@

  • Fakta bahwa jj belum mendukung light clone (git clone --filter=blob:none) memang masih belum terselesaikan

• Katanya “Jujutsu lebih kuat daripada Git”, tetapi tidak ada penjelasan konkret bagian mana yang lebih kuat, jadi saya penasaran sebenarnya kenapa saya harus memakainya. Ini terdengar seperti sekadar bumbu kata-kata

  • Saya penulis tutorialnya. Karena sasarannya pemula, perbandingan detail dengan Git tidak cocok dimasukkan. Kompleksitas UI Git sering dibenarkan atas nama “kekuatan”, jadi saya hanya ingin menambahkan klaim itu agar pembaca tahu bahwa Jujutsu bukan berarti kehilangan kemampuan hanya karena lebih mudah dipelajari

  • Sebagai contoh, Anda membuat branch baru dari branch main dan nanti berencana mengirimkannya sebagai PR. Setelah menumpuk beberapa commit, Anda merasa commit nomor 1 perlu diubah. Tinggal edit commit 1 dan simpan, lalu semua commit lain akan otomatis direbase ke keadaan terbaru. Bahkan setelah PR pun, kalau ingin mengubah commit nomor 3, cukup edit commit itu lalu push lagi, selesai. Melakukan ini langsung di Git sangat sulit. Rekan kerja saya sangat menyukai PR yang terbagi dalam beberapa commit

  • Saya juga berpikir mirip. Saya merasa UI Git pada umumnya kurang memadai, jadi saya cukup bersedia mempercayai dan memakai jj. Tetapi akan lebih bagus kalau ada demonstrasi konkret tentang “kenapa ini lebih mudah, lebih kuat, atau lebih nyaman”

  • Salah satu contohnya, merge conflict bisa dicatat sebagai satu item lalu ditangani nanti: https://jj-vcs.github.io/jj/latest/conflicts/

• Belakangan saya mencoba JJ lagi, dan sekarang jauh lebih baik sehingga saya memakainya dengan senang hati. Saat pertama kali mencoba di awal, ada banyak sisi tajam yang terasa berat, tetapi saya menganggap JJ bagian dari “gelombang baru” tooling hebat yang muncul belakangan ini. Saya juga menulis tentang itu di blog: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/

  • Tulisan yang bagus. Saya rasa standar tooling pengembang memang naik sangat tinggi dalam beberapa tahun terakhir. Rust juga bagian dari perubahan itu

  • Senang melihat Anda juga memakai dan menyukai mise. mise, jj (dan TUI jjui yang benar-benar keren), serta uv untuk Python semuanya terasa revolusioner. Saya pikir alat-alat seperti ini benar-benar indah

  • Saya juga ingin sekali menambahkan nushell ke daftar itu

  • Bun juga ada di garis depan revolusi tooling ini

• Kerja yang luar biasa! Saya hampir 5 bulan hanya memakai Jujutsu dan sepenuhnya menggantikan git. Selama itu saya sebenarnya tetap menjalankan Git 52 kali (11 di antaranya --help), tetapi Jujutsu saya pakai sampai 582 kali. Tanpa perlu menyesuaikan diri ke workflow tertentu, Jujutsu cukup fleksibel untuk mendukung hampir semua workflow. Bahkan kalau dipakai seperti git pun, Anda bisa memindahkan commit dan branch dengan bebas (tanpa perlu stash), bisa rebase dengan mudah (mungkin ini familiar bagi ahli git, tetapi sangat menyenangkan bisa melakukannya langsung tanpa alat git di VSCode), dan bisa fokus ke pekerjaan tanpa pusing pada bagian-bagian VCS yang menyebalkan. Yang perlu diperhatikan, riwayat kerja tetap tersimpan juga di repo git seperti biasa, jadi tetap kompatibel dengan alat git lain. Artinya saya bisa memakai hal berbeda tanpa mengharuskan rekan kerja mengganti VCS mereka. Ada sedikit kekurangan di tag, submodule, dan LFS, tetapi tetap sangat layak dicoba

  • Saya penasaran apa padanan jj untuk git branch --set-upstream-to

  • Kalau sudah mencoba jjui, Anda hampir tidak perlu menyentuh perintah jj lagi ke depannya. Benar-benar mengejutkan

• Jujutsu benar-benar bagus. Saya mencobanya beberapa bulan lalu dan menulis beberapa artikel tentangnya (yang ini), lalu terus memakainya sampai sekarang. Secara keseluruhan pengalamannya sangat “konsisten”. Sebenarnya saya termasuk orang yang juga tidak punya masalah memakai git, tetapi di jj semuanya berjalan berdasarkan beberapa prinsip dasar, dan bisa digabungkan sesuka hati sehingga perubahan riwayat kerja yang rumit pun jadi mudah. Dulu saya bekerja dengan gaya “serba stash”, dan jj jauh lebih nyaman daripada git berkat pelacakan perubahan otomatis, perpindahan perubahan yang bebas, dan sebagainya. Rebase dan penyelesaian konflik juga jauh lebih baik (terutama untuk workflow bergaya stash). Sangat direkomendasikan, dan usaha untuk berpindah juga sangat kecil

• Secara pribadi saya kurang suka pendekatan menambahkan lapisan baru di atas git. Saya paham sulit untuk menembus hegemoni git, tetapi saya rasa membangun di atas fondasi yang benar-benar baru akan jauh lebih kuat dan bebas

• Saya memakai jj sekitar sebulan, lalu kembali ke git karena proyek tertentu di kantor. Saya benar-benar suka jj, hanya saja tidak lebih dari itu. Tetapi beberapa jam setelah kembali ke git, saya sangat merindukan kenyamanan jj: https://blog.nawaz.org/posts/2025/Aug/the-jujutsu-effect/

  • Saya penasaran tepatnya apa maksud “tidak lebih dari itu”

  • Maksudnya, nilainya baru terasa setelah kehilangannya

• Saya ingin membaca lebih banyak dengan tema “Jutustsu for Git experts”. Misalnya, apakah melakukan commit conflict akan merusak git rerere saya, atau apakah di jj ada cara praktis untuk menerapkan patch set dua tahap seperti saat di git saya suka men-stage hanya sebagian patch dengan git add -p. Saya ingin menghindari kerusakan timestamp atau rebuild build system yang tidak berarti

  • Saya jawab dari workflow jj yang paling umum dipakai (“squash workflow”). Anda bebas mengubah apa pun di top commit yang menjadi working directory, lalu saat ingin “men-stage”, cukup squash down ke commit di bawahnya (yakni satu langkah di bawah), baik semua perubahan maupun hanya sebagian dengan -i. Selain itu, dengan squash --into Anda bisa menentukan commit lain dan melakukan squash ke posisi yang diinginkan

  • 1. jj tidak memakai git rerere, jadi pertanyaan itu agak meleset. 2. @ adalah workspace, dan @- adalah commit yang sedang Anda kerjakan. Dengan jj squash -i, Anda bisa secara interaktif mengembalikan sebagian diff yang diinginkan ke @

  • Meski saya setuju bahwa “pemisahan stage/unstage itu tidak perlu”, tetap menarik melihat pendapat “men-stage hanya bagian patch yang disukai itu sangat bagus”. Dengan kombinasi git worktree, git diff, vi, dan git apply, efek serupa bisa dicapai tanpa staging, tetapi memang sangat merepotkan. Bahkan di mercurial 7.1 masih belum ada interactive add, jadi selain akal-akalan lewat worktree tidak ada alternatif lain

• Akhir-akhir ini saya sering melihat pembicaraan tentang Jujutsu, tetapi belum masuk ke workflow konkretnya. Saya penasaran apakah Jujutsu punya keunggulan khusus dibanding Emacs Magit. Sebagian besar UI Git yang pernah saya coba terasa kurang, tetapi Magit sangat meningkatkan produktivitas git saya dan membuat saya merasakan “sihir” git. Saya ingin tahu apakah Jujutsu mencoba bersaing dengan pengalaman ini, atau tujuannya lebih sebagai alternatif untuk UI git yang sudah ada (dan memang sangat kurang)

  • Jujutsu bukan sekadar UI git; malah sebagai UI git ia cenderung lemah (dukungan untuk tag, submodule, dan sebagainya masih kurang). Ini VCS yang benar-benar baru, hanya saja memakai git sebagai backend. Jika git dulu memberi “cheap branch” dibanding SVN, JJ membawa “cheap rebase”. Conflict tidak menghentikan seluruh pekerjaan, dan rebase serta pengelolaan struktur commit benar-benar nyaman. Kalau Anda pernah memakai stacked diffs, rasanya akan familier, dan stacked diff PR di jj nyaris bisa dilakukan tanpa usaha

  • Jika Anda sudah banyak memakai Magit, konsep dasar jj juga kemungkinan akan menarik. jj memungkinkan commit acrobatics yang dulu dianggap mustahil (misalnya merebase 2 leaf dari 5-way octopus merge dalam keadaan conflict belum terselesaikan). Ini juga teknik yang saya buat dengan nama “Mega Merge”. Ada kemiripan antara Magit dan jj, dan saya rasa “sihir git” itu sebenarnya berasal dari “bahasa desain” alatnya. Git hanyalah lapisan penyimpanan fisik bagi Magit dan jj, tetapi algoritme, UX, dan konsepnya sangat berbeda. Pengguna Magit biasanya tidak terlalu kaget dengan jj, tetapi pengguna command line Git tingkat lanjut sangat mudah beralih ke jj, dan sering menjadi pendukung kuatnya. Mereka paling paham kekuatan alat yang jago memanipulasi graf commit. Sebagai catatan, saya salah satu maintainer jj, dan menurut saya ini alat yang dibuat dengan sangat baik. Cobalah memakainya beberapa hari tanpa Magit

  • Ini beberapa tautan terkait. Artikel yang menjelaskan workflow Megamerge dengan baik: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/, https://ofcr.se/jujutsu-merge-workflow, dan TUI kelas atas yang membungkus jj cli: https://github.com/idursun/jjui

  • Saya penasaran apa “konsep pusat” Jujutsu. Dibanding fakta bahwa Git adalah standar industri, saya belum benar-benar merasakan alasan kuat mengapa orang harus memakai Jujutsu. Konsepnya menurut saya menarik, tetapi kalau sudut pandang pemasarannya dibuat lebih jelas, peluang pemakaiannya bisa jauh lebih besar. Kelemahan terbesar Git adalah betapa tidak ramahnya ia untuk orang luar (istilahnya, sulit ditemukan, minim frontend GUI, dan sebagainya), jadi saya rasa VCS yang ramah pemula punya potensi besar

  • Saya pindah dari Magit ke jujutsu. Perubahan yang terasa adalah menyusun PR bertingkat jadi jauh lebih mudah, dan saya terbiasa memecah perubahan ke unit yang lebih kecil sehingga standar “cukup layak untuk dikirim” saya jadi lebih ketat. Secara umum pengalaman saya positif, tetapi kalau Magit sudah sangat cocok untuk Anda, tidak ada keunggulan yang benar-benar menentukan. Meski begitu, berkat https://github.com/bolivier/jj-mode.el, jj juga cukup nyaman dipakai di Emacs

• Menarik sekali. Walau saya cukup aktif online, ini pertama kalinya saya mendengar Jujutsu. Saya suka gagasan memberikan VCS yang lebih baik sambil tetap memakai Git sebagai backend. Salah satu alasannya adalah karena cadangan dan berbagi tetap bisa dilakukan lewat Github-Gitlab. Fossil dan Bitkeeper juga menarik, tetapi tidak cukup jauh lebih baik dari git untuk mengalahkan efek jaringan git. Saya akan mencoba memainkan Jujutsu sedikit. Saya belum tahu apakah akan terus memakainya, tetapi semoga ternyata lebih bagus dari yang saya bayangkan