Biarkan OpenCode memperbaiki bug sementara Anda tetap bekerja di worktree sendiri
OpenCode 2.2.6 bisa memulai eksekusi skrip dalam Git worktree baru. Pelajari cara meninjau hasilnya dan membatasi akses agen.
Anda sedang mengerjakan perubahan yang belum selesai di sebuah checkout ketika seseorang melaporkan pengurai tanggal yang gagal. Anda ingin terus menyunting berkas sendiri dan memberi agen pemrograman tugas terpisah. Begitu kalian mengedit direktori yang sama, usulan perbaikan sekecil apa pun sulit dipisahkan dari pekerjaan yang masih berlangsung.
Pada 6 November, OpenCode 2.2.6 menambahkan opsi worktree pada eksekusi skrip baris perintah. OpenCode adalah agen pemrograman sumber terbuka dengan antarmuka terminal interaktif dan perintah terpisah untuk menjalankan prompt dari skrip. Opsi baru memungkinkan skrip meminta OpenCode memulai di Git worktree lain, memberi nama jika perlu, dan membiarkan direktori kerja awal tersedia. Rilis yang sama menambahkan pilihan berbagi koneksi Model Context Protocol (MCP) yang konfigurasinya cocok. Dua pertanyaan patut dijawab sebelum memulai. Berkas mana yang bisa diubah agen, dan layanan mana yang bisa dipakainya? Rilis OpenCode v2.2.6 · Dokumentasi CLI OpenCode
Penyiapan yang paling berguna memadukan satu tugas terbatas, titik awal yang dapat diprediksi, tempat memeriksa perubahan, dan izin yang jelas untuk semua aktivitas di luar proyek.

Tangkapan terminal proyek OpenCode menunjukkan patch dan sesi dalam antarmukanya. Aset merek dari tag rilis memperlihatkan pengalaman terminal. Pemberitahuan lisensi MIT menyertai gambar. Telli.sh mengubah ukuran tangkapan layar dan menambahkan tepi.
Direktori terpisah menghasilkan diff yang mudah dipercaya
Git worktree memberi tiap tugas berkas kerja dan indeksnya sendiri. Ilustrasi asli Telli.sh.
Git worktree menghubungkan lebih dari satu direktori kerja ke satu repositori. Setiap worktree mendapat berkas kerja, indeks, dan posisi checkout sendiri. Sebagian besar data repositori tetap dibagi. Worktree memungkinkan Anda memeriksa patch agen secara terpisah sementara perubahan awal tetap di tempatnya. Ini juga memengaruhi kode sumber yang dilihat agen. Perubahan yang belum di-commit di direktori pertama tidak ikut masuk ke checkout kedua hanya karena keduanya memakai repositori yang sama. Dokumentasi Git worktree
Rilis OpenCode 6 November mendokumentasikan tiga cara. Gunakan opencode run -w atau opencode run --worktree untuk worktree baru, dan --worktree=<name> untuk memberi nama. Opsi worktree tidak dapat digabungkan dengan --continue atau --session. Eksekusi baru membutuhkan konteks awal baru. Untuk laporan bug dengan percakapan panjang, salin langkah reproduksi yang relevan dan hasil yang diharapkan ke prompt baru. Rilis OpenCode v2.2.6 · Implementasi worktree dan contoh
Gunakan direktori terpisah sebagai tempat meninjau. Sebelum mulai, catat branch dan commit yang seharusnya dipakai agen. Setelah mulai, periksa commit dan status worktree yang dibuat. Jika uji bergantung pada fixture yang belum dilacak atau perubahan yang hanya ada di editor pengembang, perbedaan kondisi awal itu bisa menjelaskan hasil uji yang tampak bertentangan. Patch bisa benar untuk versi kode yang lebih lama dan tetap tidak cocok untuk branch yang akan dirilis.
Coba satu perubahan kecil sebelum menyerahkan pekerjaan besar
Mulailah dengan repositori yang Anda miliki dan tugas yang terarah. Uji tanggal kabisat yang gagal lebih cocok sebagai percobaan pertama daripada peningkatan berskala luas karena hasilnya mudah diverifikasi. Contoh lain ialah memperbaiki tautan navigasi usang dengan satu uji rute. Untuk keduanya, jelaskan perilaku yang harus berubah dan cara memeriksanya setelah selesai.
-
Catat keadaan awal. Di direktori saat ini, jalankan
git status --shortdangit rev-parse HEAD. Simpan keluarannya bersama laporan bug. Jika kondisi awal sudah lolos, catat cara mengulangnya. Gunakanopencode --versionuntuk memastikan rilis mendukung opsi baru. Rilis OpenCode v2.2.6 -
Berikan satu tugas dalam worktree bernama. Masukkan reproduksi dan uji sasaran ke prompt. Contoh berikut memakai pengurai tanggal fiktif dan mengasumsikan repositori sudah memiliki uji terarah. Meminta perubahan tetap tanpa commit memudahkan pemeriksaan. Tegakkan batas yang lebih kuat lewat izin dan lingkungan eksekusi yang dipilih.
ShellJalankan di Terminalopencode run --worktree=date-parser "Reproduce the leap-day parsing bug in the date parser tests. Fix the narrow cause, run the targeted tests, and leave the changes uncommitted for review." -
Temukan direktori baru sebelum memeriksa hasil. Jalankan
git worktree listdari repositori awal, lalu gunakan jalur yang ditampilkan. Di direktori baru, periksagit status --short,git diff, dangit diff --cached. Perintah terakhir penting jika agen menambahkan sesuatu ke staging. Tinjau berkas yang belum dilacak secara terpisah. Jalankan kembali uji dari direktori agen dan pastikan uji mencakup 29 Februari pada tahun kabisat serta tahun ketika tanggal itu tidak valid. Dokumentasi Git worktree -
Bawa pulang hanya pekerjaan yang sudah ditinjau. Simpan usulan perubahan secara terpisah sampai commit atau patch yang ditinjau dapat diterapkan ke branch tujuan. Periksa ulang status direktori awal. Pertahankan worktree agen sampai semua yang diperlukan tercatat dan dipastikan tidak ada perubahan tertunda yang ingin disimpan. Daftar worktree Git membantu mengenali direktori tiap tugas. Dokumentasi Git worktree
Pola sama berguna saat dua masalah tak berkaitan datang bersamaan. Beri masing-masing lingkup kecil dan bandingkan kedua diff sebelum menggabungkan salah satunya. Pemisahan mencegah perubahan uji agen yang belum masuk staging muncul di direktori lain. Kedua perbaikan masih bisa bentrok saat bertemu di branch yang sama, terutama jika menyentuh fungsi bantu yang sama. Integrasi branch dan uji regresi terakhir tetap mengikuti proses peninjauan biasa.
Tentukan siapa bisa melakukan apa di luar repositori
Dua worktree dapat berjalan dengan akun sistem operasi yang sama. Keduanya mungkin punya akses ke lingkungan, pembantu kredensial, dan jaringan yang sama. Opsi worktree baru memilih tempat eksekusi dimulai dan memisahkan perubahan rutin. Gunakan batas lingkungan eksekusi atau akun yang terpisah jika tugas memerlukan perlindungan lebih kuat. Permintaan izin mengatur alat yang mematuhinya, sedangkan sistem operasi atau lingkungan eksekusi menentukan apa yang pada akhirnya bisa dijangkau proses.
Pisahkan lokasi perubahan dari persetujuan alat dan akses lingkungan eksekusi. Ilustrasi asli Telli.sh.
Dokumentasi izin OpenCode V2 menjelaskan aturan berurutan untuk tiap tindakan. Efeknya mencakup allow, ask, dan deny, dengan aturan terakhir yang cocok berlaku. Salah satu contoh resmi meminta persetujuan untuk perintah shell, mengizinkan perintah inspeksi umum, dan menolak push. Jika tidak ada pemberi persetujuan, uji perilaku aturan ask dalam alur tersebut sebelum menjadikannya pekerjaan berulang. Masukkan larangan yang jelas dalam konfigurasi dan pakai kredensial berumur pendek dengan cakupan terbatas untuk layanan yang benar-benar dibutuhkan. Dokumentasi izin OpenCode
| Keputusan | Yang dapat diperiksa dalam uji coba |
|---|---|
| Tempat perubahan dibuat | Commit awal, worktree agen, diff yang sudah dan belum masuk staging, keluaran pengujian |
| Yang bisa dipanggil agen | Aturan berkas dan shell yang berlaku, alat MCP yang tersedia, perilaku ketika alat ditolak |
| Yang bisa dijangkau proses | Izin akun, direktori yang dipasang, kredensial, dan tujuan jaringan |
| Yang masuk ke proyek | Patch yang sudah ditinjau manusia dan pemeriksaan integrasi yang lolos |
Tugas dokumentasi saja memberi cara mudah menguji lapisan ini. Izinkan agen mengubah satu bagian proyek contoh. Beri penyedia yang boleh digunakan tanpa kredensial produksi. Jalankan skrip dan pastikan patch hanya menyentuh berkas yang diharapkan. Jika otomasi berikutnya memerlukan remote repositori atau alat tiket, jelaskan alasan tiap kemampuan dan verifikasi izinnya sendiri.
Berbagi koneksi masuk akal jika batas akses kedua proyek sama
MCP memungkinkan agen memakai alat dari program lain, seperti pencarian dokumentasi atau pelacak isu. Dalam rilis 6 November, pool: true memungkinkan direktori yang dilayani satu server OpenCode memakai ulang koneksi jika konfigurasi terkait cocok. Dokumentasi V2 menyebut penggunaan kumpulan koneksi untuk revisi protokol 2026-07-28. Jika server menegosiasikan revisi lama, koneksi tetap terpisah. Kesamaan alamat saja belum cukup. Pengaturan jarak jauh dan akun terautentikasi harus cocok. Untuk server lokal, kecocokan mencakup perintah, lingkungan, dan direktori kerja. Rilis OpenCode v2.2.6 · Dokumentasi berbagi koneksi MCP OpenCode
Bayangkan dua worktree menggunakan layanan dokumentasi internal yang sama dengan akun yang sama. Berbagi bisa mengurangi penyiapan koneksi ganda jika layanan mendukung revisi tersebut. Pastikan dahulu kedua direktori memang boleh mengakses materi yang sama dan integrasi hanya menyediakan kemampuan yang dibutuhkan. Jika satu worktree hanya perlu dokumentasi publik sementara yang lain dapat membuka tiket internal, koneksi terpisah memudahkan pemeriksaan batasnya.
Server lokal bisa bergantung pada direktori kerja aktif. Proses yang diluncurkan di folder proyek berbeda dapat memperoleh konteks berbeda meskipun teks perintah sama. Dokumentasi OpenCode menyebut direktori kerja tetap sebagai syarat pengumpulan koneksi lokal lintas proyek, dan koneksi bersama tidak memiliki roots. Mulailah dari layanan baca-saja yang menunjukkan cakupan sumber dayanya. Jika perilaku alat bergantung pada repositori yang memanggil, ukur perubahan sebelum memakai koneksi bersama. Dokumentasi berbagi koneksi MCP OpenCode
Eksekusi skrip tetap perlu berakhir
OpenCode 2.2.6 juga menambahkan --archived agar sesi skrip atau CI bisa dimulai sebagai arsip dan tidak muncul dalam daftar sesi biasa. Itu mengubah penyajian sesi. Simpan hasil pekerjaan, jalur worktree, dan hasil uji di tempat yang bisa ditemukan peninjau. Pakai opsi setelah ada cara menemukan patch terkait meskipun daftar biasa kosong. Catatan 6 November menyebut sesi arsip dilewati oleh --continue. Rilis OpenCode v2.2.6
Rilis yang sama mengubah siklus hidup eksekusi skrip. Proses menunggu perintah latar, subagen, dan pekerjaan gambar dari prompt sebelum keluar. Catatan rilis menyebut penantian itu tidak memiliki batas internal, sehingga server pengembangan atau pemantau berkas bisa membuat proses tetap terbuka. Untuk uji otomatis, pilih perintah yang keluar setelah pemeriksaan selesai dan beri batas waktu pada langkah CI. Bedakan sesi dibatalkan, uji gagal, dan agen melaporkan keberhasilan. Jika waktu habis, periksa keadaan perubahan yang diusulkan sebelum memulai ulang atau mengintegrasikan. Rilis OpenCode v2.2.6
Setelah uji coba berjalan, nilai penghematan waktu dengan melihat lebih dari pesan selesai dari agen. Berapa lama penyiapan eksekusi baru? Berapa lama peninjau memahami dan memverifikasi perubahan? Seberapa sering orang perlu memperbaiki suntingan di luar lingkup atau menyelidiki alat yang macet? Bandingkan beberapa tugas seukuran dan masukkan waktu penyiapan serta peninjauan. Worktree terpisah paling berguna ketika patch tetap cukup kecil untuk dipahami penanggung jawab.
Checkout yang bersih memperjelas tanggung jawab
Manfaat opsi worktree adalah peninjau punya tempat mulai yang jelas. Ia dapat melihat kondisi awal, memeriksa perubahan, dan mengulang uji selagi pengembang lain terus bekerja. Tetapkan berbagi koneksi dan izin eksekusi dengan kejelasan yang sama. Serah terima yang baik berupa patch kecil yang menjelaskan titik awal, perubahan, dan bukti bahwa perubahan siap diintegrasikan.
Sumber
Agar keputusan dan eksperimen di balik pekerjaan mudah dicari, buat akun Telli.sh.