Kamus Pindahan: Perintah Git yang Kamu Cari di jj
Padanan perintah git sehari-hari di jj, dan kenapa sebagian perintah itu tidak perlu diketik lagi.
Jam tiga sore. Working copy lagi setengah jadi: dua file controller berubah, satu tes belum lulus. Lalu masuk pesan, minta tolong cek bug kecil di main. Jari saya sudah hafal urutannya: git stash, git checkout main, git checkout -b fix-bug-kecil.
Di jj, tiga perintah itu tidak punya padanan satu-satu. Sebagian malah tidak perlu diketik sama sekali.
Itu yang paling membingungkan di hari-hari pertama pindahan. Kamu tidak sedang belajar sintaks baru untuk hal yang sama. Beberapa perintah git ada karena model git membutuhkannya, dan begitu modelnya ganti, perintahnya ikut hilang. Artikel sebelumnya membahas model itu: working copy adalah commit. Artikel ini kamusnya.
Yang tidak berubah
jj status dan jj diff bekerja seperti yang kamu kira. jj log sedikit beda: langsung tampil sebagai graph, tanpa --graph --oneline --all yang biasanya kamu alias sendiri.
Mulai dari tiga ini dulu. Rasa asingnya turun cepat kalau hal pertama yang kamu ketik ternyata familiar.
Kamusnya
| Di git | Di jj |
|---|---|
git add . && git commit -m "..." | jj commit -m "..." |
git commit --amend | tidak perlu apa-apa |
git checkout -b fitur | jj new |
git checkout <commit> | jj edit <change-id> |
git stash | jj new |
git cherry-pick <commit> | jj duplicate <change-id> |
git reset --hard | jj undo |
Tujuh baris, lima perintah. Satu baris isinya “tidak perlu apa-apa”, dua baris jawabannya sama. Itu bukan kebetulan, dan di situ letak pelajarannya.
jj commit -m sebenarnya dua langkah yang digabung: jj describe -m (kasih pesan ke commit yang sedang kamu kerjakan) lalu jj new (segel commit itu, buka commit kosong berikutnya). Tidak ada add, karena semua perubahan di disk sudah masuk ke commit @ setiap kali kamu menjalankan perintah jj apa pun.
Amend hilang karena commit yang sedang kamu kerjakan memang masih terbuka. Edit file, selesai. Mau ganti pesannya, jj describe -m "..." lagi.
Satu catatan buat yang kerja bareng agen: selalu pakai -m. jj describe tanpa -m membuka editor, dan agen yang menunggu editor tidak akan pernah selesai. Kami kena persis ini di jj split. Agennya tidak error, tidak jalan, cuma diam.
checkout -b dan stash sama-sama jadi jj new, karena di git dua-duanya cuma cara menyelamatkan kerja yang belum di-commit sebelum pindah konteks. Di jj, kerja itu sudah commit. Kasus jam tiga sore tadi cukup satu baris:
jj new 'trunk()'Commit baru, kosong, di atas trunk. Kerjaan setengah jadi tetap duduk di commit-nya sendiri, tidak disimpan di laci mana pun. Bug kecil beres, balik lagi dengan jj edit <change-id>. Kamu juga tidak wajib bikin branch. Nama baru dibutuhkan nanti, saat mau push.
jj edit memindahkan kamu ke commit mana pun dan langsung membuka isinya untuk diedit. Turunannya ikut di-rebase otomatis. Pakai change ID (deretan huruf seperti qpvuntsm), bukan hash. Change ID tetap sama walaupun isinya ditulis ulang sepuluh kali.
jj duplicate adalah cherry-pick: salinan commit dengan change ID baru, yang bisa kamu taruh di mana saja.
jj undo paling beda rasanya. git reset --hard membuang kerja. jj undo mundur satu operasi, apa pun operasinya, dan undo itu sendiri bisa dibatalkan. Detailnya di artikel berikutnya.
git rebase -i sengaja tidak masuk tabel. Padanannya tersebar ke jj rebase dan jj squash, dan lebih enak dibahas bareng stack di artikel kelima.
Perintah git yang tidak punya padanan bukan fitur yang hilang. Itu tambalan untuk masalah yang tidak ada di jj.
Empat konsep yang bergeser
Commit bisa berubah secara default. Di git, mengubah commit lama itu upacara. Di jj itu kegiatan biasa, karena change ID menjaga identitasnya.
Branch jadi bookmark, dan bookmark tidak ikut maju waktu kamu bikin commit baru. Ini yang paling sering menjebak. Bookmark cuma perlu saat kamu mau push, dan kamu sendiri yang menggesernya. Di repo internal core kami, satu tumpukan kerja campur dipecah jadi 8 change, dan baru di ujung masing-masing dikasih bookmark supaya jadi 8 MR. Branch datang belakangan.
Konflik jadi data, bukan penghenti kerja. Rebase yang kena konflik tetap selesai. Commit-nya ditandai konflik, dan kamu bisa menyelesaikannya kapan saja. Waktu main maju dan 6 bookmark kami harus dipindah serentak, tidak ada satu pun rebase yang berhenti di tengah dan minta --continue.
Reflog diganti op log. Reflog cuma mencatat pergerakan HEAD. Op log mencatat semua operasi di seluruh repo. Ini jaring pengamannya, dan dapat artikel sendiri.
Revset: log yang bisa ditanya
Satu kebiasaan baru yang worth it dipelajari di minggu pertama:
jj log -r 'trunk()..@'
jj log -r 'mine()'Yang pertama menampilkan semua pekerjaan saya yang belum masuk trunk. Yang kedua, semua commit yang saya tulis. Perlakukan -r sebagai klausa WHERE di SQL: kamu tidak menggulir log sambil mencari, kamu bertanya ke log.
Praktiknya, trunk()..@ jadi perintah yang paling sering saya ketik sebelum push. Kalau ada commit asing di situ, berarti ada yang belum beres.
Di git kamu membaca history. Di jj kamu meng-query-nya.
Satu hal yang perlu diingat: kalau perintah git yang kamu cari tidak ada padanannya di jj, kemungkinan besar masalah yang dia selesaikan juga tidak ada.
Berikutnya: Op log, jaring pengaman yang bikin berani eksperimen.
Bahan dasar: panduan Git Differences di lazyjj.dev oleh Ernesto Jiménez.