Jujutsu untuk Developer yang Sibuk

• Jujutsu (jj) adalah sistem kontrol versi yang menawarkan konsep dan perintah yang lebih sederhana daripada Git, namun tetap menyediakan fitur yang kuat
• Karena menggunakan Git sebagai backend, ada keuntungan berupa bisa dipakai bersamaan atau dengan mudah kembali ke Git
• Fitur seperti stacked diff, rebase yang mudah, dan revisi sementara tersedia secara alami
• Menggunakan konsep bookmark alih-alih branch, sehingga lebih intuitif untuk alur kerja di lapangan
• Cara menangani konflik fleksibel dan membuat pekerjaan kontrol versi sehari-hari jauh lebih sederhana

---

Elevator Pitch

Jujutsu (jj) adalah sistem kontrol versi yang menyediakan model mental dan antarmuka baris perintah yang jauh lebih sederhana dibandingkan Git.
Tanpa mengorbankan fitur, bahkan bisa dibilang lebih kuat
Fitur seperti stacked diff, rebase yang mudah, dan revisi sementara bekerja secara alami
Karena menggunakan Git sebagai backend, Anda bisa mulai memakainya berdampingan dengan repositori Git hanya dengan satu baris, dan kapan saja kembali ke Git
Juga tidak memengaruhi cara pengguna lain menangani repositori tersebut

Getting Started

• Setelah memasang alat baris perintah jj, disarankan untuk mengatur informasi pengguna dan pelengkapan otomatis shell
• Saat diterapkan ke repositori yang sudah ada, lebih baik melakukan clone baru atau mulai menggunakannya saat tidak ada perubahan
• Di repositori yang sudah ada, Anda bisa membuat repositori Git dan Jujutsu secara berdampingan dengan perintah jj git init --colocate .
• Data repositori jj disimpan di folder .jj/ yang terpisah dari .git milik Git
• Sinkronisasi data antara Git dan Jujutsu pada dasarnya berjalan tanpa masalah
• Namun, perhatikan bahwa perintah git clean -fdx akan menghapus folder .jj/
• Pelacakan remote branch juga bisa diatur sekaligus dengan perintah tersebut

How To Use It

Antarmuka baris perintah Jujutsu lebih sempit dan ringkas daripada Git
Konsep dasarnya sederhana, tetapi alur kerjanya memerlukan sedikit adaptasi
Cara penggunaan utamanya dijelaskan lewat prosedur dan contoh sederhana

Starting A New Revision

• Di Git, pekerjaan baru biasanya dimulai dengan membuat branch, tetapi Jujutsu menggunakan cara membuat revisi baru
• Mencerminkan status terbaru repositori remote: jj git fetch
• Melihat riwayat repositori: jj log
• Revisi dalam riwayat dibedakan dengan ID revisi khas Jujutsu dan hash commit Git
• Untuk memulai pekerjaan baru, gunakan jj new main untuk membuat revisi baru di atas main saat ini
• Revisi yang sedang diedit dibedakan dengan simbol @
• Jika prefiks yang sama hilang, prefiks pendek dari ID revisi juga akan berubah ikutannya

Making Changes

• Jika file diubah, perubahan itu langsung termasuk ke revisi tersebut (tidak ada staging area terpisah)
• Setelah selesai mengubah, tambahkan pesan ke revisi dengan jj describe -m "pesan"
• Untuk membuat revisi baru, gunakan jj new (atau tentukan revisi sebelumnya)
• jj commit adalah operasi gabungan dari jj describe + jj new

Navigating

• Revisi kosong yang dibuat dengan jj new akan dibuang otomatis saat berpindah
• Menghapus revisi secara eksplisit: jj abandon <rev ID>
• Membatalkan penghapusan: jj op undo
• Kembali ke revisi yang sudah ada: jj edit <rev ID>
• Saat merujuk revisi, ekspresi revset juga bisa digunakan:
  • @: revisi saat ini
  • x-: revisi induk
  • y+: revisi anak
  • z::: semua keturunan dari z

Branches (Bookmarks)

• Jujutsu tidak memiliki keadaan "sedang berada di branch" seperti Git
• Sebagai gantinya, bookmark hanyalah pointer yang menunjuk revisi tertentu
• Membuat bookmark baru: jj bookmark create <nama> -r <revisi>
• Meski sudah commit, bookmark tidak berpindah otomatis, jadi jika perlu harus dipindahkan secara terpisah dengan jj bookmark move <nama> --to <revisi>
• Saat push, pembuatan branch baru di remote diizinkan dengan flag --allow-new
• Jika bookmark berbeda dengan remote, akan ditandai dengan * dan bisa disinkronkan dengan jj git push

Conflicts

• Cara menangani konflik di Jujutsu lebih fleksibel daripada Git
• Saat konflik terjadi, tanda ‘conflicted’ akan muncul pada revisi dan revisi turunannya
• File yang konflik akan disisipi conflict marker, dan penyelesaiannya dilakukan dengan menghapus marker tersebut
• Anda bisa memperbaikinya langsung atau membuat perubahan di revisi baru lalu menggabungkannya dengan jj squash

Kesimpulan

Sekian panduan tentang cara menangani 80% pekerjaan yang paling sering dilakukan di Git dengan lebih sederhana menggunakan Jujutsu
Pemakaian umum/lanjutan akan disediakan kemudian dalam bentuk handbook referensi (Quick Reference)
Seperti Git, perintah jj status juga didukung
Pertanyaan atau masukan bisa dikirim lewat email yang tercantum di isi tulisan

[GN⁺]

Komentar Hacker News

• Ada satu hal yang ingin saya tekankan bagi yang sedang mempertimbangkan apakah jj layak dipelajari.
  Kalau membahas jj di Hacker News, biasanya orang terbagi jadi dua kubu: yang belum pernah mencoba, dan yang sangat merekomendasikannya.
  Saya hampir tidak pernah melihat orang kembali ke git setelah memakai jj selama seminggu.
  Hampir semua orang yang benar-benar memakainya dengan serius akhirnya menetap di jj.
  Semoga hari ini jadi momen Anda mencoba jj.
  Peralihannya jauh lebih sederhana dari yang dibayangkan; saya bahkan tetap produktif di hari pertama, dan dalam seminggu tidak perlu kembali ke perintah git sama sekali.
  Dalam waktu singkat saya jadi lebih produktif, sampai terasa aneh memikirkan dulu saya memakai git bagaimana.

  • Saya sama sekali tidak merasa git mengganggu produktivitas.
    Saya juga tidak menghabiskan waktu lama setiap hari memakai perintah git, dan di kebanyakan kasus tidak ada masalah dalam bekerja.
    Kalau Anda harus banyak memanipulasi repo dengan git, mungkin jj lebih baik, tapi itu tidak berlaku untuk situasi saya.
    Ini mirip seperti disuruh pasti mencoba bim, yang sangat mirip vim tetapi punya beberapa fitur tambahan.
    Tapi saya tidak penasaran soal harus menekan i beberapa kali lebih sedikit, dan juga tidak butuh autocomplete Julia.
    Silakan dinikmati bagi yang merasa jj lebih baik.

  • jj memang jelas sebuah kemajuan dalam UI VCS, tetapi bagi pengguna tingkat lanjut git ada beberapa keterbatasan.
    Karena tidak mendukung gitattributes, akan merepotkan kalau Anda butuh filter seperti git-crypt atau git-lfs.
    Kompatibilitas di Windows, seperti penanganan akhir baris, juga bisa lebih buruk.
    Selain itu, tool eksternal seperti git-annex atau git-bug tidak terintegrasi dengan oplog dan bisa membuat riwayat jadi berantakan.

  • Saya benar-benar pernah memakainya lebih dari seminggu lalu kembali ke git.
    Secara pribadi saya lebih suka workflow dengan staging area; kebanyakan orang tidak suka git staging, tetapi bagi saya keuntungannya tidak cukup besar sampai layak dikorbankan di jj.
    Mungkin kebiasaan itu bisa diubah, tetapi untuk sekarang saya belum merasa perlu terikat ke jj.
    Saya tetap terbuka untuk mencobanya lagi suatu saat.

  • Saya sempat memakai jj selama beberapa bulan lalu kembali ke git karena masalah performa.
    Operasi di jj memakan waktu beberapa detik, sementara git selalu terasa instan tanpa peduli ukuran proyek.
    Selain itu, saat memakai jj saya merasa ada sedikit beban mental tambahan, dan ketika kembali ke git rasanya jauh lebih ringan.
    Mungkin ini juga karena pengalaman panjang saya memakai git.

  • Pernyataan “toh cuma ada dua kubu” itu sendiri terdengar seperti kalimat khas para penginjil jj.

• Hal yang membuat saya gila di jj adalah semua perubahan otomatis masuk staging.
  Dulu SVN juga begitu, dan saya merasa git justru jauh lebih baik karena staging dilakukan secara eksplisit.
  Di repo selalu ada lebih banyak perubahan, dan memilih hanya yang ingin dimasukkan ke commit berikutnya itu hal yang wajar di git.
  Di jj (termasuk SVN), sebelum commit Anda perlu repot memindahkan perubahan keluar untuk sementara dan melakukan kerja manual yang merepotkan.

  • Ini juga dilema bagi saya.
    Staging selalu terasa merepotkan, jadi dulu saat memakai Mercurial pun saya kesulitan.
    Kalau auto add dibutuhkan lebih dari 90% waktu, justru itu terasa nyaman, tetapi file yang tidak bisa dimasukkan ke .gitignore jadi masalah.
    Kalau auto add dimatikan jadi tidak nyaman, kalau dinyalakan juga terasa serba tanggung.
    Tidak ada pilihan yang benar-benar rapi.

  • Workflow JJ agak berbeda, jadi misalnya Anda membuat base commit dulu lalu menumpuk commit anonim di atasnya sambil bekerja.
    Saat sudah siap, Anda bisa merapikannya dengan jj squash atau jj split.

  • Saya memakai jj commit -i atau opsi -i di banyak perintah lain, serta snapshot.auto-track="none()" di config.
    Dulu saat memakai Mercurial saya juga mirip begitu.
    Dalam praktiknya, kalau sering memakai fitur absorb, file atau chunk yang tidak diperlukan biasanya otomatis diabaikan.

  • Bukankah perintah jj new cocok untuk workflow yang Anda inginkan?

  • jj melacak branch yang bukan head di dalam tree dengan benar, jadi rebase dan merge bisa berjalan mulus tanpa perlu stash.

• Saya sulit beradaptasi dengan penambahan perubahan otomatis.
  Kadang di lokal saya mengubah file tertentu hanya sementara dalam proses development tanpa niat untuk ikut di-commit.
  Di git saya tenang karena kalau tidak di-stage maka itu tidak akan pernah ter-commit atau ter-push.
  Di jj rasanya saya harus unstage sesuatu atau ekstra hati-hati.
  Mungkin ini soal kebiasaan, tetapi saya lebih nyaman ketika saya yang jelas-jelas menentukan apa yang akan saya commit.
  Saya jadi penasaran apakah saya salah memahami jj.

  • Di jj Anda bisa membagi perubahan dengan jj split.
    Yang Anda pilih akan masuk ke revisi pertama, sisanya ke revisi kedua.
    Kalau Anda mengerjakan beberapa hal sekaligus lalu memecahnya jadi revisi kecil-kecil, ini jauh lebih mudah daripada git.
    Seperti di git, Anda bisa membuat revisi baru (jj new), melakukan perubahan, lalu memindahkan hanya bagian yang diinginkan dengan jj squash -i.
    Secara konsep, “@” adalah revisi saat ini dan “@-” adalah satu langkah sebelumnya, jadi bisa dianggap mirip working copy/stage di git.

  • Auto staging di jj tidak selalu bagus.
    Saya harap dokumentasi resmi jj dan para pemula yang memperkenalkannya bisa lebih jelas memberi tahu bahwa default ini mudah dimatikan.
    Di ~/.jjconfig, tulis saja:
    [snapshot]
    auto-track = "none()"
    seperti ini.

  • Biasanya setelah selesai bekerja saya memakai jj split untuk meninjau dan merapikan bagian yang akan di-commit.
    Workflow ini bergerak mirip add -p di git.
    Commit paling atas biasanya bisa dipakai seperti working copy yang tidak di-push.
    Bahkan kalau pindah branch tanpa stash, pekerjaan yang sedang berjalan tetap tersimpan dengan baik.

  • Ya, kebiasaan itu juga tidak mudah berubah bagi saya.
    Dasar logis dari argumen bahwa kebiasaan itu memang perlu diubah adalah bahwa kode seharusnya tidak dijalankan dalam keadaan untracked.
    Perubahan yang bermakna sebaiknya tersimpan dalam commit, dan sisanya tidak perlu dicatat; itu lebih aman.
    Masalahnya muncul ketika pengaturan seluruh repo dan pengaturan lokal tidak terpisah, dan VSCode adalah contoh yang khas.
    Dalam kasus seperti ini, Anda jadi memerlukan perubahan yang tidak boleh di-commit untuk tiap lingkungan, sehingga situasinya makin rumit.

  • Kalau Anda menginginkan workflow seperti itu, Anda bisa menganggap “@” di jj seperti index di git, lalu saat commit melakukan squash ke “@-”, sehingga efeknya mirip git add --patch.

• Saya sedang mencoba mengalihkan tim ke jj tapi sejauh ini gagal.
  Akan bagus kalau ada halaman yang bisa langsung menunjukkan seberapa mudah pekerjaan rumit di git dilakukan di jj.
  Sederhana seperti elevator pitch.
  Saya juga merasa mungkin perlu mendemokannya sendiri secara langsung.

  • Banyak pekerjaan git yang umum dipakai sepertinya tidak otomatis jadi lebih mudah di jujutsu.
    Sebaliknya, jujutsu punya workflow baru yang di git mustahil atau merepotkan.
    Itu mungkin tidak langsung terasa bagi developer yang sudah terbiasa dengan git.

  • Saya sendiri juga tidak terlalu suka git.
    Dulu saya hanya memakai mercurial, tetapi sekarang git sudah telanjur tertanam di kepala saya.
    Walaupun Jujutsu punya kelebihan yang jelas, saya masih belum merasa cukup tertarik sampai mau repot mengurus setup awal seperti pengaturan warna yang rumit atau skrip-skrip yang sudah akrab.

  • Satu perbandingan pekerjaan representatif antara jj dan git sangat membantu pemahaman saya.
    https://lottia.net/notes/0013-git-jujutsu-miniature.html

  • Saya juga merekomendasikan beberapa tautan bagus yang mungkin membantu.
    https://v5.chriskrycho.com/essays/jj-init/
    https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/
    https://ofcr.se/jujutsu-merge-workflow

  • Anda mungkin akan menyukai bagian berikutnya yang segera saya tambahkan ke post ini.
    Saya berencana memuatnya di bagian bawah halaman dan juga sebagai post terpisah dalam waktu dekat.

• Setelah beberapa minggu memakai jj, saya bahkan membuat skrip pesan commit otomatis.
  Hari ini saya mencoba mem-port skrip yang sama ke repo git lama, lalu sadar bahwa di git saya perlu menulis kode yang bisa mendeteksi secara otomatis apakah saat itu sedang commit atau amend.
  Di jj, berkat struktur commit yang immutable, skripnya jadi sangat sederhana.
  Akhirnya saya langsung clone ulang repo itu dengan jj.
  Saya seketika terbebas dari kebingungan antara commit dan amend.
  https://codeberg.org/jcdickinson/nix/src/branch/main/home/common/scripts/jj-auto.fish

  • Tidak perlu sampai clone ulang; Anda cukup menambahkan jj ke repo git yang sudah ada.

• git bekerja dengan cukup baik.
  Kurva belajarnya memang ada sedikit, tetapi begitu dipahami semuanya masuk akal.
  Sejujurnya, di 95% situasi cukup tahu pull, add, reset, branch, dan commit.

  • Dalam workflow saya, stacked diff itu wajib.
    Ini bagus untuk menumpuk pekerjaan lanjutan tanpa terblokir karena menunggu review.
    Di git, setup-nya tidak terlalu sulit, tetapi menambahkan perubahan ke bagian bawah stack lalu melakukan restack seluruhnya benar-benar neraka.

  • Kalau bekerja kolaboratif, memahami rebase/squash itu wajib.
    Sulit menghindarinya sebelum Anda berhasil meyakinkan seluruh tim untuk tidak memakainya.
    Terutama ketika beberapa orang buru-buru mengembangkan sesuatu di satu branch yang sama, kebiasaan git terasa tidak nyaman.
    Secara dasar memang nyaman, tetapi dalam situasi rumit masalahnya banyak.

  • Bahkan hanya dengan mengalami situasi yang tidak biasa saja, kelemahan git mulai terlihat.

• Saya sudah sekitar dua minggu memakai jj, dan untuk pertama kalinya saya merasa nyaman memakai version control hanya dari command line.
  Saat memakai git, saya selalu bergantung pada GUI (Git Graph di VSCode) dan banyak klik kanan.
  Dengan jj, hanya setelah membaca tutorial saya bisa langsung masuk ke command line yang konsisten.
  Tapi sepertinya saya harus belajar bahasa revset agar tidak terus-menerus copy-paste id di log jj.

  • Saya juga berada di situasi yang mirip.
    Saya sudah lama memakai git, tetapi urusan yang rumit selalu saya tangani lewat UI.
    Sudah hampir sebulan saya hanya memakai jj CLI dan cukup puas.
    Meski begitu, dokumentasi resmi jj ditulis dengan asumsi pembaca sudah punya pengetahuan dasar, jadi bagi pemula kadang membingungkan.
    Saya berharap lebih banyak blog dan tutorial bermunculan.
    Saya juga ingin belajar lebih jauh tentang bahasa revset dan rebase.
    Saya suka CLI-nya yang ringkas, penyelesaian konflik, dan oplog.

  • Saya juga dulu tidak suka harus copy-paste id, tetapi setelah memakai jjui(https://github.com/idursun/jjui) semuanya terasa jauh lebih mulus.
    Rasanya jadi bisa bekerja cepat sambil menyapu log dengan lancar.

• Menurut saya fitur terbaik jj adalah undo.
  Di git, undo itu sulit karena perintahnya berbeda tergantung jenis kesalahan.
  Di jj cukup sekali jj undo.
  Ia juga tidak mengikat ke sistem backend tertentu, jadi walau Anda memakai jj sendirian secara lokal, rekan kerja Anda tidak akan terdampak.

• Saya masih bingung sebenarnya jj itu apa.
  Apakah ini front-end untuk orang yang bingung dengan git?
  Katanya melakukan abstraksi backend, tetapi pengaruh git terasa terlalu kuat sehingga saya sulit membayangkannya pada sistem seperti Perforce atau Piper yang memaksa commit bernomor urut.
  Desain working copy = commit menurut saya membuat quality control jadi tidak mungkin.
  Makna asli commit adalah hanya memasukkan hal-hal yang memang disengaja, tetapi dengan struktur seperti ini rasanya akan makin sulit membedakan “commit sampah”.
  Baik git maupun jj sama-sama tampak lemah untuk proyek besar, dan sepertinya tetap tidak bisa mencegah commit yang bertebaran.
  Saya penasaran masalah apa sebenarnya yang diselesaikan jj; jangan-jangan ini cuma front-end sesuai selera penulisnya.

  • Backend Piper justru berjalan lebih alami daripada backend Git.
    Commit jj tidak sepenuhnya berkorespondensi dengan commit git, jadi tidak perlu salah paham.
    Dalam praktiknya, ketika kita mengatakan “commit”, maksudnya lebih seperti “diff yang diberi nama”, dan perubahan sebelum push kapan saja bisa dengan mudah dibongkar lalu dirapikan ulang.
    Ini jauh lebih nyaman daripada rebase dan penyuntingan history di git.
    Saya sering membuat beberapa commit eksperimen, dokumentasi, dan sebagainya di tengah pekerjaan, yang di git biasanya harus saya paksa masuk ke stash atau branch sementara.

  • jj lebih dari sekadar front-end git.
    Ia adalah sistem version control dan backend-agnostic.
    Backend utamanya memang git, jadi Anda bisa langsung beralih di repo yang sudah ada.
    Saya pengguna git sejak sebelum GitHub muncul, tetapi setelah memakai jj saya tidak bisa kembali ke git.
    jj lebih sederhana sekaligus lebih kuat.
    working copy = commit sebenarnya lebih tepat dipahami sebagai “index juga adalah sebuah commit”.
    Misalnya saat mulai mengerjakan feature x, Anda membuat commit baru dengan jj new -m "working on feature x" trunk, lalu menumpuk satu commit kosong lagi di atasnya.
    Hasil kerja masuk ke working copy (@), lalu Anda “memindahkannya” (squash) ke commit sebelumnya (@-), jadi alih-alih mengandalkan opsi rumit seperti add-p atau reset di git, semuanya ditangani sebagai diff antar-commit.
    Berkat struktur ini, pemisahan dan perapian commit bisa dilakukan dengan lebih fleksibel dan kuat dibanding index git.
    Masalah banjir commit lebih dekat ke budaya pull request, dan jj pun hanya bisa membantu sebagian.

  • Working copy tidak sembarangan di-push ke GitHub; saat Anda menambahkan deskripsi commit, Anda bisa sekaligus meninjau dan merapikannya.

• Saya sudah mencoba jj beberapa hari, tetapi saya sudah cukup puas dengan lazygit, workflow saya sekarang, dan setup skrip yang ada.
  jj memang terasa segar dan lumayan bagus, tetapi kecuali Anda baru mulai memakai version control, rasanya belum ada motivasi kuat untuk pindah.

  • Kalau memakai tool lain seperti GitButler, front-end jadi tidak terlalu penting, tetapi beberapa hari lalu saya mulai memakai Jujutsu dan cuma dengan bertanya ke Claude soal operasi utama (commit, pindah branch, push/pull ke GitHub), saya sudah lancar dalam 10 menit.
    Saya masih memakai diff dari Lazygit, tetapi meskipun berada dalam state detached HEAD tidak ada masalah sama sekali.
    JJ sangat kompatibel dengan git, dan tanpa perlu menghafal perintah rumit, ia membuat semuanya jauh lebih mudah.
    Saat berpindah antar-branch, file yang belum di-commit otomatis ikut berpindah adalah fitur terbaik.
    Ini membuat pekerjaan bolak-balik antara development, perbaikan bug, dan perubahan copy jadi sangat mudah.
    Kalau agen AI yang melakukan perubahan, Anda tinggal memisahkan worktree untuk dipakai.
    Saya juga sangat suka karena deskripsi perubahan (= pesan commit) bisa diberi sebelum pekerjaan selesai dan ditinjau lebih dulu di tree.
    Secara keseluruhan JJ benar-benar sangat bagus.