Git Worktree: Kerja di Banyak Branch Sekaligus

Pernah mulai refactor besar, lalu mendadak harus memperbaiki bug di branch produksi? Pilihan lama biasanya cuma dua: menyimpan pekerjaan setengah jadi lewat git stash, atau meng-clone repository untuk kedua kalinya. git worktree memberi jalan ketiga — satu repository, banyak direktori kerja, masing-masing memegang branch sendiri.

Fitur ini menghapus ritual “stash dulu, nanti lupa di-pop”. Artikel ini membahas pemakaian praktisnya, dari membuat worktree sampai membersihkan yang sudah selesai. Semua perintah mengacu ke manual resmi Git 2.56.0 dan diuji ulang di Git 2.43.0.

Kenapa Satu Direktori Kerja Tidak Cukup

Stash menyimpan perubahan pada tingkat diff. Begitu working tree berisi file baru yang belum dilacak sekaligus file yang dipindah, memulihkan kondisi itu jadi pekerjaan tersendiri; konflik saat pop juga biasa terjadi kalau branch tujuan sudah bergerak.

Clone kedua menyelesaikan isolasi, tapi mahal: riwayat diunduh lagi, kredensial diatur ulang, dan dua salinan gampang tertukar saat push. Worktree mengambil jalan tengah — direktori kerja terpisah secara fisik, sementara database objek, refs, dan konfigurasi tetap satu. Efeknya terasa di hal kecil: vendor atau node_modules di worktree kedua tidak mengganggu build di worktree utama.

Apa yang Sebenarnya Terjadi di Balik Layar

Repository Git punya satu main worktree — direktori tempat git init atau git clone dijalankan — dan nol atau lebih linked worktree. Setiap linked worktree mendapat subdirektori administrasi sendiri di dalam $GIT_DIR/worktrees, misalnya .git/worktrees/hotfix, berisi penanda seperti file gitdir, HEAD, dan index milik worktree tersebut.

Yang dibagi bersama: objek commit, semua ref di bawah refs/, dan file config utama. Yang terpisah: HEAD, index, serta ref semacam refs/bisect, refs/worktree, dan refs/rewritten. Karena objeknya dipakai bersama, commit di worktree mana pun langsung terlihat di worktree lain tanpa fetch.

Membuat Worktree Pertama

Bentuk paling sederhana cukup satu baris. Perintah berikut membuat direktori ../hotfix sekaligus branch baru hotfix dari commit aktif:

git worktree add ../hotfix -b hotfix

Tanpa -b, Git memakai komponen terakhir dari path sebagai nama branch, jadi git worktree add ../hotfix hasilnya sama. Kalau branch itu sudah ada, Git check out branch lama, bukan membuat yang baru — asalkan belum dipakai worktree lain.

Dua variasi yang sering dibutuhkan: mengecek branch yang sudah ada, dan membuat worktree sekali pakai tanpa branch.

# review branch orang lain tanpa mengubah working tree utama
git worktree add ../review-payment feature/payment

# eksperimen bebas, HEAD terlepas dari branch mana pun
git worktree add -d ../coba-perf

Opsi -d adalah singkatan dari --detach: cocok untuk benchmark atau percobaan yang belum layak masuk branch, dan bisa dibuang tanpa meninggalkan branch menggantung.

Tiga Pola yang Paling Sering Kepakai

Menambal bug saat refactor belum selesai

Contoh dari manual Git sendiri: working tree berantakan karena refactor, lalu muncul permintaan perbaikan mendesak. Buat worktree dari commit stabil, kerjakan perbaikan, push, lalu hapus. Refactor tetap utuh di direktori lama, termasuk file yang belum di-commit.

Review pull request tanpa mengganggu pekerjaan

Daripada berpindah branch di direktori utama — yang memaksa dev server restart dan cache dibangun ulang — arahkan branch reviewer ke worktree terpisah. Di sana bebas menjalankan migrasi atau menghapus file sementara, lalu dibersihkan dengan git worktree remove.

Membandingkan dua versi berdampingan

Ketika bug hanya muncul di rilis lama, dua direktori berarti dua editor dan dua terminal tanpa commit-setor-checkout berulang. Untuk proyek Laravel, ini berguna saat membandingkan perilaku setelah upgrade framework, sementara environment lokal tetap ditangani lewat Laravel Valet di Linux.

Membaca Daftar Worktree

Untuk tahu direktori mana memegang branch apa, pakai perintah berikut. Worktree utama selalu muncul di baris pertama, diikuti linked worktree lain sesuai urutan pembuatan.

git worktree list
# /srv/app          d4e2b06 [main]
# /srv/app-hotfix   d4e2b06 [hotfix]
# /srv/app-exp      5c1a9f2 (detached HEAD)

git worktree list --porcelain

Format default memberi anotasi locked untuk worktree terkunci dan prunable untuk yang direktorinya sudah hilang; mode --verbose memindahkan anotasi ke baris berikutnya beserta alasannya.

Untuk script pakai --porcelain: satu atribut per baris, dipisah baris kosong antar record, dan formatnya stabil lintas versi Git. Tambahkan -z kalau path bisa mengandung karakter newline.

Batasan: Satu Branch untuk Satu Worktree

Branch yang sudah ter-check out di satu worktree tidak bisa dipakai worktree lain; Git menolak dengan pesan fatal: 'hotfix' is already used by worktree at '/srv/app-hotfix'. Opsi --force bisa memaksa, tapi dua worktree pada branch yang sama akan saling menimpa index. Solusi sehatnya: pakai branch berbeda, atau worktree sementara dengan HEAD terlepas.

Worktree utama tidak bisa dipindah dengan git worktree move, begitu juga linked worktree yang berisi submodule. Kalau direktori utama dipindah manual, jalankan git worktree repair agar tautannya tersambung lagi.

Membersihkan Worktree dengan Rapi

Tutup worktree lewat perintahnya sendiri, bukan dengan menghapus folder di file manager. remove menolak direktori yang masih punya perubahan belum di-commit, jadi sekaligus berfungsi sebagai pengaman:

git worktree remove ../hotfix

# kalau folder sudah telanjur dihapus manual
git worktree list
git worktree prune --dry-run --verbose
git worktree prune --expire now

Setelah folder dihapus manual, catatan administrasinya tertinggal dan worktree tampil prunable. prune --dry-run --verbose menunjukkan apa yang akan dibuang, sedangkan --expire now memaksa pembersihan tanpa menunggu masa tunggu. Tanpa intervensi, Git membersihkannya sendiri mengikuti gc.worktreePruneExpire; kalau ingin rutin dan tercatat, jadwalkan lewat systemd timer.

Untuk worktree di perangkat portabel yang kadang tidak ter-mount, kunci dengan git worktree lock --reason "disk eksternal" ../arsip. Kunci juga mencegahnya dipindah atau dihapus.

Konfigurasi yang Hanya Berlaku di Satu Worktree

Config repository dipakai bersama secara default. Untuk pengaturan berbeda per direktori — misalnya sparse checkout hanya di satu worktree — aktifkan git config extensions.worktreeConfig true, lalu tulis nilainya dengan flag --worktree: git config --worktree core.sparseCheckout true.

Setelah aktif, pengaturan spesifik disimpan di config.worktree. Pengecualian penting: core.bare dan core.worktree tidak lagi otomatis hanya untuk worktree utama, jadi pindahkan ke config worktree utama bila ada di config bersama. Repository dengan ekstensi ini tidak bisa dibaca Git versi lama.

Kapan Worktree Bukan Jawaban

Butuh isolasi total. Kalau dua versi aplikasi butuh dependency sistem berbeda atau port Docker yang sama, clone terpisah lebih aman karena tidak ada state yang dibagi.
Direktori dependency besar. Objek Git dipakai bersama, tapi node_modules, vendor, dan cache build tetap digandakan per worktree.
Kebutuhan CI. Pipeline yang butuh checkout bersih cukup memakai clone dangkal.

Pegangannya: worktree unggul saat yang dibutuhkan adalah beberapa branch dari satu repository yang sama. Begitu kebutuhannya bergeser ke isolasi environment, pindah ke clone atau container.

FAQ

Apakah worktree menyalin seluruh riwayat repository?

Tidak. Hanya direktori kerja baru yang dibuat; objek, ref, dan config tetap satu. Karena itu membuat worktree jauh lebih cepat daripada clone.

Bisakah satu branch dipakai dua worktree sekaligus?

Tidak, Git menolaknya karena index dan HEAD akan bertabrakan. Pakai branch terpisah, atau buat worktree dengan --detach kalau hanya ingin melihat kode pada commit tertentu.

Apa bedanya worktree dengan submodule?

Worktree adalah direktori kerja tambahan untuk repository yang sama, sedangkan submodule adalah repository lain yang ditanam di dalam repository induk. Keduanya bisa dipakai bersamaan.

Kesimpulan

Worktree menutup celah antara stash yang serba terbatas dan clone yang boros. Tiga perintah cukup untuk mulai: add untuk membuat, list untuk memeriksa, remove untuk menutup. Sisanya soal disiplin — tutup lewat perintahnya, dan pangkas yang tertinggal secara berkala.

Kalau terminal jadi penuh perintah panjang, bikin alias seperti di artikel custom terminal Oh My Zsh. Kebiasaannya sederhana: sebelum menyentuh branch lain, tanya dulu apakah masalahnya bisa diselesaikan dengan direktori kerja kedua.