Git worktrees, yapay zekâ kodlama agent'lerinin dosya çakışması olmadan paralel çalışmasını sağlıyor

Tek repo, çok fazla agent

Claude Code veya Codex gibi bir araçta tek bir yapay zekâ kodlama oturumu genellikle sorunsuz çalışır. Sorun, servatj'nin yakın tarihli bir dev.to gönderisinde anlattığı gibi, aynı anda ikinci bir görev çalıştırmak istediğinizde başlar — bir terminalde login, diğerinde payments. Her iki agent de aynı çalışma dizinini ve aynı checkout edilmiş dalı paylaşır, böylece iki otomatik süreç aynı dosyaları aynı anda düzenlemeye başlar. Yazarın çözümü, yıllardır var olan ama günlük iş akışlarında nadiren yer bulan bir Git özelliği: git worktree.

Worktrees size ne kazandırır

Worktree, aynı depoyu temel alan ek bir çalışma dizinidir. Her dizin kendi dalını checkout ederken hepsi aynı nesneleri, commit'leri ve dal listesini paylaşır. Gönderi, kurulumu ana checkout üzerinden gösteriyor:

git worktree add ../integration -b integration main git worktree add ../feature-login -b feature/login main git worktree add ../feature-payments -b feature/payments main

Sonuç, ana checkout'un yanı sıra integration, feature/login ve feature/payments için ayrı dizinler içeren bir proje klasörü. Her agent bir klasör ve bir terminal alır ve hiçbiri başka bir agent'in dosyalarına dokunmaz.

Push ya da pull olmadan birleştirme

Yazarın beklemediği kısım, bitmiş bir dalı push edip başka yerde pull etme şeklindeki ekip iş akışı refleksinin burada gereksiz olması. Tüm worktree'ler aynı makinedeki aynı depoya aittir, dolayısıyla Git zaten her dalı yerel olarak bilir. Login agent'i commit ettikten sonra integration worktree'si feature/login'i doğrudan merge eder, test paketini çalıştırır ve sonunda integration'ı main'e geri birleştirir. Bu döngünün hiçbir yerinde push ya da pull görünmez.

Dallar, worktree'leri hâlâ varken de birleştirilebilir. Git'in tek kısıtlaması, aynı dalın aynı anda iki worktree'de checkout edilememesidir — ki yazarın da belirttiği gibi, bu tam da birden fazla agent söz konusu olduğunda isteyeceğiniz korumadır.

Temizlik bilerek yumuşak tutulmuş. Bir klasörü elle silmek yerine git worktree remove dizini siler ve Git'in iç kaydını günceller; bir klasör zaten elle silinmişse git worktree prune sonradan defter tutumunu onarır. Dalı git branch -d ile silmek döngüyü tamamlar.

GitHub nerede devreye giriyor

Aynı makinede iş birliği yapan agent'ler için GitHub'ın hiçbir rolü yok — koordinasyon mekanizması Git'in kendisidir. Remote, insanlar devreye girdiğinde yerini kazanır; pull request, kod incelemesi, CI ve bir denetim izi sağlar. Yazar sonucu iki ayrı düzlem olarak tanımlıyor: agent'lerin commit ettiği, bir integration dalına merge ettiği ve testleri çalıştırdığı yerel bir düzlem; insanların push ettiği, incelediği ve CI'ın doğrulamasına izin verdiği uzak bir düzlem.

Yazarın öne çıkardığı bir ayrıntı, integration agent'inin asla başka bir agent'in klasörünü okumaması ya da kodunu kopyalamaması. Yalnızca dal adlarını bilir, dolayısıyla Git fiilen agent'ler arasındaki iletişim kanalı olarak davranır.

Runtime hâlâ paylaşılıyor

Worktree'ler dosyaları ve dalları yalıtır, runtime'ı değil. Her biri bir dev server ve bir Playwright paketi çalıştıran iki agent 3000 numaralı port için yarışacak, aynı test veritabanına erişecek ve her headless tarayıcı için hatırı sayılır miktarda bellek tüketecektir. Yazarın bugün kullandığı geçici çözüm gösterişsiz: her worktree, oluşturulma anında yazılan bir env dosyasıyla kendi portunu alır ve Playwright base URL'i için bu dosyayı okur. Test veritabanlarını yalıtmak, birden fazla tarayıcı paketini dizginlemek ve integration'ın uçtan uca testleri çalıştırmasına izin verilen tek worktree olup olmayacağına karar vermek, yazarın bir sonraki yazıda ele almayı planladığı açık sorular.

Neden önemli

Birden fazla yapay zekâ kodlama agent'ini paralel çalıştırmak hızla normal bir çalışma biçimi haline geliyor ve sürtünmenin çoğu sıradan şeylerden kaynaklanıyor: çakışan düzenlemeler, paylaşılan portlar, birbirine dolanan dallar. Bu kalıp yeni bir araç gerektirmiyor. Uzun süredir var olan bir Git özelliğini geliştiricilerin zaten elinde olan terminaller ve agent'lerle birleştiriyor ve makineye özgü agent döngüsünü insan incelemesi döngüsünden temiz biçimde ayırıyor; böylece pull request ve CI olduğu gibi kalıyor. Runtime yalıtımı ve paylaşılan kaynaklar çevresindeki eksiklikler gerçek, ancak temel iş akışı bireysel bir geliştiricinin ya da bir ekibin birkaç komutla bugün benimseyebileceği bir şey.