Worktree itu mudah dibuat dan mudah dilupakan. Anda membuatnya supaya agen bisa mengerjakan sebuah branch secara terisolasi, agen menyelesaikannya, Anda meninjau diff-nya, lalu direktori itu cuma tergeletak begitu saja. Seminggu kemudian, git worktree list menggulir keluar dari layar, du -sh pada repo menunjukkan dua belas gigabyte, dan tiga dari direktori itu menunjuk ke branch yang sudah di-merge dan dihapus beberapa hari sebelumnya. Tidak ada yang sengaja menyimpannya. Semuanya menumpuk karena pembuatannya cukup satu perintah, sementara pembersihannya jadi pekerjaan yang merepotkan.
Inilah bagian dari kerja agen paralel yang tidak pernah diperingatkan oleh siapa pun. Primitif isolasinya sudah terdokumentasi dengan baik; panduan kami tentang worktree git untuk agen coding AI membahas mekanisme pembuatan dan branching secara mendalam. Justru siklus hidup setelah "selesai" itulah sumber masalahnya, dan kondisinya memburuk dengan cepat ketika yang membuat worktree adalah agen yang bisa membuka lima worktree dalam satu menit dan tidak punya naluri untuk merapikan. Artikel ini membahas paruh belakang itu: disiplin pembersihan, perintah persisnya, mode kegagalan yang menanti di setiap langkah, dan titik ketika skrip buatan sendiri tidak lagi memadai.
Sharkly adalah salah satu jawaban atas masalah "siapa yang membersihkan": Sharkly menjalankan setiap Task di worktree-nya sendiri dan memperlakukan worktree itu sebagai bagian dari siklus hidup Task, bukan sebagai direktori yang harus Anda ingat. Kita akan sampai ke sana. Tapi pertama, mekanismenya, karena Anda sebaiknya memahami versi manualnya sebelum memutuskan untuk berhenti melakukannya dengan tangan.
TL;DR
Git worktree adalah direktori kerja kedua yang terhubung ke satu repositori, dengan branch, index, dan HEAD-nya sendiri. Agen membuat worktree menumpuk karena setiap eksekusi menginginkan isolasi dan tidak ada satu pun yang membersihkan setelah dirinya sendiri. Rel pembersihannya terdiri dari empat perintah: git worktree list untuk melihat apa yang ada, git worktree remove untuk menghapus worktree yang sudah selesai, git worktree prune untuk membersihkan metadata basi, dan git worktree lock untuk melindungi worktree yang ingin Anda pertahankan. Masing-masing punya mode kegagalan yang bisa meninggalkan direktori yatim, pekerjaan yang hilang, atau branch yang terkunci jika Anda melewatkan satu langkah. Versi manualnya cukup untuk segelintir worktree. Di luar itu, kaitkan setiap worktree dengan catatan task agar pembersihan punya pemilik, dan itulah yang dilakukan Sharkly secara otomatis.
Mengapa worktree menumpuk lebih cepat saat memakai agen
Worktree punya siklus hidup yang secara alami dikelola manusia: Anda membuatnya, Anda bekerja, Anda melakukan merge, lalu Anda menghapusnya. Langkah penghapusan bergantung pada manusia yang mengingatnya. Agen merusak asumsi itu dari dua arah sekaligus.
Pertama, volume. Satu developer yang menjalankan empat agen secara paralel membuat empat worktree per jam, bukan satu per hari. Postingan kami tentang menjalankan beberapa agen Claude Code secara paralel membahas mengapa jumlah itu naik begitu cepat. Kedua, tidak ada naluri membersihkan. Agen membaca task, mengerjakan pekerjaannya, menulis hasilnya, lalu berhenti. Agen tidak berpikir "branch-nya sudah di-merge, jadi direktori ini sekarang cuma beban mati." Akibatnya, direktori-directori itu hidup lebih lama dari kegunaannya, dan yang tersisa itulah masalahnya: checkout basi pada branch yang sudah dihapus, eksperimen setengah jadi yang ditinggalkan agen, dan pohon node_modules duplikat yang memakan disk di setiap worktree.
Biayanya bukan hal abstrak. Setiap worktree adalah checkout penuh plus apa pun yang dipasang agen ke dalamnya. Sepuluh worktree pada repo JavaScript ukuran menengah berarti sepuluh direktori node_modules. Disk penuh, git status melambat di seluruh set, dan orang berikutnya yang menjalankan git worktree list tidak bisa membedakan direktori mana yang masih berisi pekerjaan aktif dan mana yang sudah jadi sampah.
Rel pembersihan, langkah demi langkah
Berikut seluruh siklus hidupnya dalam empat perintah. Jalankan sesuai urutan ini dan mode kegagalannya tetap tertutup.
Lihat apa yang ada. Mulai setiap sesi pembersihan dari sini:
git worktree list
# /repo a1b2c3d [main]
# /repo-auth-refactor 4d5e6f7 [auth-refactor]
# /repo-fix-logging 8g9h0i1 [fix-logging]
Mode kegagalan jika Anda melewatinya: Anda menghapus direktori yang salah. Dua agen pada branch dengan nama yang mirip menghasilkan jalur worktree yang juga mirip, dan menghapus yang masih aktif berarti Anda kehilangan pekerjaan yang belum di-commit. Baca daftarnya sebelum menyentuh apa pun.
Hapus yang sudah selesai. Setelah branch sebuah worktree sudah di-merge dan Anda sudah memastikan tidak ada perubahan yang belum tersimpan di dalamnya:
git worktree remove /repo-fix-logging
Mode kegagalannya: remove akan menolak jika worktree memiliki perubahan yang belum di-commit atau file untracked, dan itu memang perilaku default yang aman. Langkah yang tidak aman adalah langsung memakai --force supaya errornya hilang. --force pada worktree yang kotor akan menghapus pekerjaan nyata yang dihasilkan agen tetapi belum pernah di-commit. Jika remove mengeluh, periksa dulu direktorinya; keluhan itu biasanya benar.
Bersihkan metadata yang basi. Jika direktori worktree dihapus dengan rm -rf alih-alih git worktree remove, git masih menyimpan catatan administratifnya. Itulah orphan yang klasik:
git worktree prune
git worktree prune --dry-run # preview first
Mode kegagalannya: melewatkan prune akan meninggalkan entri hantu di git worktree list dan, lebih buruk lagi, git bisa menolak memakai ulang branch yang menurutnya masih di-checkout di suatu tempat. prune membersihkan pembukuan itu. Jalankan --dry-run terlebih dahulu agar Anda melihat apa yang akan dibuang sebelum benar-benar dibuang. Dokumentasi git worktree menjelaskan secara persis apa yang dianggap basi oleh prune.
Kunci worktree yang ingin Anda pertahankan. Worktree di drive eksternal yang lambat, atau yang menyimpan eksperimen berjalan lama, tidak boleh dipangkas oleh skrip pembersihan yang agresif:
git worktree lock /repo-experiment --reason "release repro, keep until 2.0 ships"
Mode kegagalannya: tanpa lock, tugas pembersihan malam hari yang memangkas apa pun yang "basi" bisa menghapus worktree yang sengaja Anda simpan. Lock plus string alasan adalah pembeda antara skrip pembersihan yang Anda percaya dan skrip yang akhirnya Anda matikan setelah menelan sesuatu yang penting.
Kapan skrip pembersihan berhenti bisa diskalakan
Anda bisa mengotomatiskan keempat langkah itu. Cron job yang mendaftar worktree, memeriksa setiap branch terhadap riwayat merge, lalu menghapus yang sudah di-merge hanya butuh tiga puluh baris shell. Cara itu berhasil, dan untuk developer solo yang menjalankan beberapa agen, itu sudah cukup. Pakailah skrip tersebut selama jumlah worktree masih sedikit dan repositorinya dimiliki satu orang.
Yang membuatnya berhenti diskalakan adalah penilaian, bukan throughput. Sebuah skrip bisa tahu bahwa sebuah branch sudah di-merge. Skrip tidak bisa tahu bahwa sebuah worktree menyimpan pekerjaan agen yang belum di-commit dan belum Anda tinjau, atau bahwa branch yang "basi" sebenarnya adalah task yang dijeda dan berniat dilanjutkan seseorang. Begitu pembersihan menuntut pemahaman atas maksud sebuah worktree, aturan yang hanya melihat status git pada akhirnya akan menghapus sesuatu yang penting. Batas lainnya adalah koordinasi: pada mesin bersama, skrip pembersihan satu orang tidak tahu apa yang sedang dikerjakan agen orang lain, dan pertanyaan "apakah ini aman dihapus" tidak lagi bisa dijawab hanya dari git worktree list. Untuk pembahasan lebih lanjut soal masalah mesin bersama ini, lihat kumpulan kami tentang tools untuk mengelola agen coding AI paralel.
Apa yang ditambahkan papan task
Solusinya adalah memberi setiap worktree pemilik yang bertahan lebih lama dari sesi shell. Kaitkan setiap worktree dengan catatan task, dan pembersihan tidak lagi soal "direktori mana yang terlihat basi", melainkan "task mana yang sudah selesai dan ditinjau."
Inilah lapisan tempat Sharkly berada. Anda sudah punya coding agent; Sharkly mengubahnya menjadi tim dengan menjadikan setiap eksekusi sebagai Task. Saat sebuah Task dimulai, layanan lokal di Computer yang terhubung akan menyiapkan worktree terisolasi untuknya. Ketika hasil Task kembali untuk ditinjau dan seseorang menerimanya, siklus hidup worktree berakhir bersama Task tersebut alih-alih tertinggal sebagai direktori yang tidak diingat siapa pun. Pertanyaan pembersihan punya jawaban karena worktree itu tidak pernah anonim.
Pembagian kerjanya tetap jujur. Agen mengambil task, bekerja di worktree terisolasi, menjalankan tes, dan mengembalikan diff. Manusia menetapkan arah dan memutuskan langkah merge serta rilis. Sharkly bukan pengganti Claude Code, Codex, atau perintah git di atas; Sharkly menambahkan catatan bersama agar isolasi, kemajuan, hasil, dan pembersihan tetap terlihat dari permintaan hingga rilis alih-alih tersebar di berbagai terminal. Jika Anda hanya menjalankan satu agen dan pembersihan manual hanya butuh sepuluh detik, Anda belum memerlukannya. Ketika daftar worktree sudah menggulir keluar dari layar, masalah manajemen itulah masalah sebenarnya, dan catatan kami tentang menjaga manusia tetap dalam loop di seluruh eksekusi agen membahas sisi peninjauannya.
Checklist yang bisa Anda jalankan hari ini
Jalankan langkah ini pada repo mana pun tempat agen pernah bekerja:
git worktree listdan bacalah sepenuhnya sebelum menghapus apa pun.- Untuk setiap worktree yang sudah selesai: pastikan branch-nya sudah di-merge, periksa direktorinya bersih, lalu
git worktree remove(jangan pernah pakai--forcepada tree yang kotor). git worktree prune --dry-run, tinjau hasilnya, lalugit worktree pruneuntuk membersihkan metadata yatim.git worktree locksetiap worktree yang sengaja Anda pertahankan, beserta string alasannya.- Periksa disk:
du -shdi seluruh kumpulan worktree, dan hapus instalasi dependensi duplikat dari tree yang sudah mati. - Jika Anda melakukannya lebih dari sekali sehari, berhentilah membuat skrip pembersihan dan beri setiap worktree pemilik Task.
Anda bisa tetap memakai keempat perintah itu dan menjalankannya sendiri, atau menjalankan coding agent Anda yang sudah ada melalui Sharkly agar worktree dibuat, dilacak, dan dipensiunkan bersama Task yang memilikinya.
