Worktree oluşturmak kolaydır, unutmak da öyle. Bir agent'ın bir branch üzerinde izole biçimde çalışabilmesi için bir tane açarsınız, agent işini bitirir, diff'i incelersiniz ve sonra o dizin öylece kalır. Bir hafta sonra git worktree list çıktısı ekrandan taşar, repoda du -sh on iki gigabayt gösterir ve o dizinlerden üçü günler önce merge edilip silinmiş branch'leri işaret eder. Kimse onları bilerek tutmamıştır. Oluşturmak bir komut, temizlik ise angarya olduğu için birikmişlerdir.
Bu, paralel agent çalışmasının kimsenin sizi uyarmadığı kısmı. İzolasyonu sağlayan temel yapı iyi belgelenmiş durumda; AI kodlama agent'ları için git worktree'ler rehberimiz oluşturma ve branch açma mekaniklerini ayrıntılı biçimde ele alıyor. Asıl sızı, "iş bitti" dedikten sonraki yaşam döngüsünde ve worktree'leri oluşturan şey, bir dakika içinde beş tane açabilen ve toparlanma içgüdüsü olmayan bir agent olduğunda bu hızla daha da kötüleşiyor. Bu makale işin o arka yarısıyla ilgili: temizlik disiplini, kullanmanız gereken komutlar, her adımda pusuya yatan hata senaryosu ve elle yazılmış bir script'in nerede yetersiz kalmaya başladığı.
Sharkly, "temizliği kim yapıyor" sorununa bir yanıt: her Task'ı kendi worktree'sinde çalıştırıyor ve o worktree'yi hatırlamak zorunda olduğunuz bir dizin olarak değil, Task'ın yaşam döngüsünün bir parçası olarak ele alıyor. Oraya geleceğiz. Önce mekanikler, çünkü elle yapmayı bırakmaya karar vermeden önce manuel sürümü anlamanız gerekiyor.
TL;DR
Bir git worktree, tek bir repoya bağlı, kendi branch'i, index'i ve HEAD'i olan ikinci bir çalışma dizinidir. Agent'lar bunları üst üste yığar çünkü her çalıştırma izolasyon ister ve hiçbiri arkasını toplamaz. Temizlik hattı dört komuttan oluşur: nelerin var olduğunu görmek için git worktree list, bitmiş olanı silmek için git worktree remove, bayat metadata'yı temizlemek için git worktree prune ve saklamak istediğinizi korumak için git worktree lock. Her birinin, bir adımı atlarsanız geride yetim dizinler, kaybolan işler ya da kilitlenmiş branch'ler bırakan bir hata senaryosu var. Manuel sürüm bir avuç worktree için işe yarar. Bunun ötesinde, her worktree'yi bir görev kaydına bağlayın ki temizliğin bir sahibi olsun; Sharkly bunu otomatik olarak yapar.
Agent'larla worktree'ler neden daha hızlı birikir
Bir worktree'nin, insanın doğal olarak yönettiği bir yaşam döngüsü vardır: oluşturursunuz, çalışırsınız, merge edersiniz, silersiniz. Silme adımı, bir insanın hatırlamasına bağlıdır. Agent'lar bu varsayımı aynı anda iki yönden kırar.
Birincisi, hacim. Paralel olarak dört agent çalıştıran bir geliştirici günde bir değil, saatte dört worktree oluşturuyor. Birden fazla Claude Code agent'ını paralel çalıştırma yazımız bu sayının neden bu kadar hızlı arttığını anlatıyor. İkincisi, temizlik içgüdüsünün olmaması. Bir agent görevi okur, işi yapar, sonucu yazar ve durur. "Branch merge edildi, artık bu dizin ölü yük" diye düşünmez. Böylece dizinler kendi faydalarını aşarak hayatta kalır ve asıl sorun da hayatta kalanlardır: silinmiş branch'lerdeki bayat checkout'lar, agent'ın yarıda bıraktığı deneyler ve her birinde disk yiyen kopya node_modules ağaçları.
Maliyet soyut değil. Her worktree tam bir checkout, artı agent'ın içine kurduğu her şey demek. Orta boy bir JavaScript reposunda on worktree, on node_modules dizini eder. Disk dolar, git status tüm set genelinde yavaşlar ve git worktree list çalıştıran bir sonraki kişi hangi dizinlerin canlı iş, hangilerinin moloz olduğunu ayırt edemez.
Temizlik hattı, adım adım
İşte dört komutla tüm yaşam döngüsü. Bunları bu sırayla çalıştırın, hata senaryoları kapalı kalsın.
Var olanı görün. Her temizlik turuna buradan başlayın:
git worktree list
# /repo a1b2c3d [main]
# /repo-auth-refactor 4d5e6f7 [auth-refactor]
# /repo-fix-logging 8g9h0i1 [fix-logging]
Bu adımı atlarsanız ortaya çıkan hata senaryosu: yanlış dizini silersiniz. Benzer isimli branch'lerdeki iki agent, benzer isimli worktree yolları üretir ve canlı olanı kaldırmak size commit'lenmemiş işe mal olur. Bir şeye dokunmadan önce listeyi okuyun.
Bitmiş olanı kaldırın. Bir worktree'nin branch'i merge edildikten ve içinde kirli bir şey olmadığını doğruladıktan sonra:
git worktree remove /repo-fix-logging
Hata senaryosu: worktree'de commit'lenmemiş değişiklikler veya izlenmeyen dosyalar varsa remove reddeder; bu güvenli varsayılandır. Güvensiz hamle, hatadan kurtulmak için --force'a uzanmaktır. Kirli bir worktree üzerinde force, bir agent'ın ürettiği ama hiç commit'lemediği gerçek işi siler. remove itiraz ederse önce dizine bakın; bu uyarı genellikle haklıdır.
Bayat metadata'yı temizleyin. Bir worktree dizini git worktree remove yerine rm -rf ile silindiyse, git hâlâ onunla ilgili bir yönetim kaydı tutar. Klasik yetim tam da budur:
git worktree prune
git worktree prune --dry-run # preview first
Hata senaryosu: prune'u atlamak git worktree list içinde hayalet kayıtlar bırakır ve daha kötüsü, git bir yerde hâlâ checkout edilmiş sandığı bir branch'i yeniden kullanmayı reddedebilir. prune, defter kayıtlarını temizler. Önce --dry-run çalıştırın ki neyi düşüreceğini, düşürmeden önce görün. git worktree dokümantasyonu prune'un tam olarak neyi bayat saydığını açıklıyor.
Saklamak istediklerinizi kilitleyin. Yavaş bir harici sürücüdeki bir worktree ya da uzun süreli bir denemeyi barındıran bir worktree, agresif bir temizlik script'i tarafından prune edilmemelidir:
git worktree lock /repo-experiment --reason "release repro, keep until 2.0 ships"
Hata senaryosu: kilit olmadan, "bayat" olan her şeyi prune eden bir gecelik temizlik işi, bilerek park ettiğiniz bir worktree'yi kaldırabilir. Kilit ve bir gerekçe metni, güvendiğiniz bir temizlik script'i ile önemli bir şeyi yedikten sonra devre dışı bıraktığınız script arasındaki farktır.
Temizlik script'i nerede ölçeklenmeyi bırakır
Dört adımın hepsini otomatikleştirebilirsiniz. Worktree'leri listeleyen, her branch'i merge edilmiş geçmişle karşılaştıran ve merge edilmiş olanları kaldıran bir cron job, otuz satırlık shell kodudur. Çalışır ve birkaç agent çalıştıran tek bir geliştirici için yeterlidir. Worktree sayısı azken ve reponun sahibi tek bir kişiyken script'i kullanın.
Ölçeklenmeyi bıraktığı nokta hız değil, muhakemedir. Bir script bir branch'in merge edildiğini söyleyebilir. Ama bir worktree'nin henüz incelemediğiniz commit'lenmemiş agent işini barındırdığını ya da "bayat" görünen bir branch'in aslında birinin devam etmeyi planladığı duraklatılmış bir görev olduğunu söyleyemez. Temizlik, bir worktree'nin niyetini bilmeyi gerektirdiği anda, yalnızca git durumunu gören bir kural eninde sonunda önemli olan bir şeyi siler. Diğer tavan da koordinasyon: paylaşılan bir makinede bir kişinin temizlik script'i, başka birinin agent'larının ne yaptığını bilmez ve "bunu kaldırmak güvenli mi" sorusu tek başına git worktree list'ten yanıtlanamaz hale gelir. Bu paylaşılan makine sorunu hakkında daha fazlası için paralel AI kodlama agent'larını yönetmeye yönelik araçlar derlememize bakın.
Bir görev panosu ne katar
Çözüm, her worktree'ye shell oturumundan daha uzun yaşayan bir sahip vermektir. Her worktree'yi bir görev kaydına bağlayın; temizlik artık "hangi dizinler bayat görünüyor" olmaktan çıkıp "hangi görevler bitti ve incelendi" haline gelir.
Sharkly'nin durduğu katman burası. Kodlama agent'larınız zaten var; Sharkly her çalıştırmayı bir Task'a dönüştürerek onları bir ekibe çeviriyor. Bir Task başladığında, bağlı Computer'daki yerel servis onun için izole bir worktree hazırlar. Task'ın sonucu incelemeye döndüğünde ve bir kişi onu kabul ettiğinde, worktree'nin yaşam döngüsü kimsenin hatırlamadığı bir dizin olarak oyalanmak yerine Task'la birlikte sona erer. Temizlik sorusunun bir yanıtı vardır çünkü worktree hiçbir zaman anonim olmamıştır.
İş bölümü dürüst kalıyor. Agent'lar görevleri üstlenir, izole worktree'lerde çalışır, testleri koşturur ve diff'i döndürür. İnsanlar yönü belirler, merge ve release adımına karar verir. Sharkly, Claude Code, Codex ya da yukarıdaki git komutlarının yerini almaz; paylaşılan kaydı ekler; böylece izolasyon, ilerleme, sonuçlar ve temizlik terminallere dağılmak yerine talepten release'e kadar görünür kalır. Tek bir agent çalıştırıyorsanız ve elle temizlik on saniye sürüyorsa, buna henüz ihtiyacınız yok. Worktree listesi ekrandan taşmaya başladığında asıl sorun yönetim sorunudur ve agent çalışmaları boyunca insanı döngüde tutma notumuz bunun inceleme tarafını ele alıyor.
Bugün çalıştırabileceğiniz kontrol listesi
Agent'ların çalıştığı herhangi bir repoda bu turu yapın:
- Bir şeyi kaldırmadan önce
git worktree listçalıştırın ve tamamen okuyun. - Bitmiş her worktree için: branch'in merge edildiğini doğrulayın, dizinin temiz olduğunu kontrol edin, sonra
git worktree remove(kirli bir ağaçta asla--forcekullanmayın). git worktree prune --dry-run, inceleyin, sonra yetim metadata'yı temizlemek içingit worktree prune.- Bilerek tuttuğunuz her worktree'yi bir gerekçe metniyle
git worktree lockile kilitleyin. - Diski kontrol edin: worktree seti genelinde
du -shve ölü ağaçlardaki kopya bağımlılık kurulumlarını silin. - Bunu günde birden fazla yapıyorsanız, temizliği script'lemeyi bırakın ve her worktree'ye bir Task sahibi verin.
Dört komutu koruyup elle çalıştırabilir ya da mevcut kodlama agent'larınızı Sharkly üzerinden çalıştırabilirsiniz; böylece worktree, ait olduğu Task'la birlikte oluşturulur, izlenir ve emekliye ayrılır.
