Paralel kodlama agent'larını git worktree'lerde çalıştırmak

İki kodlama agent'ını aynı checkout'ta çalıştırın; yazılım ekiplerinin neden dal kullandığını hemen anlarsınız. Bir agent bir modülün adını değiştirirken diğeri test suite'ini bu değişikliğin yarısına karşı koşturur. Biri, diğerinin az önce sildiği dosyaları stage'e alır. İkisi de hatalı değil; sadece aynı masayı paylaşıyorlar.

SuperDevSpace bir manager'ı ve birkaç worker'ı aynı repoda aynı anda çalıştırır. Bu yazı onları birbirinden ayıran mekanizmayı — git worktree'leri — ve uygulamanın bunlar etrafında uyduğu kuralları anlatıyor.

Git worktree nedir

Bir git reposunun normalde tek bir çalışma dizini vardır. git worktree aynı repoya birden çok çalışma dizini verir; her biri kendi dalında checkout edilmiştir ve hepsi aynı nesne veritabanını paylaşır. İkinci bir clone ya da geçmişin ikinci bir kopyası yoktur: yeni bir worktree yalnızca bir checkout'un dosyaları kadar yer kaplar.

Herhangi bir repoda elle deneyebilirsiniz. Komutlar her yerde aynı; değişen yalnızca kabuk:

git worktree add -b agent/frontend-demo ../myrepo-frontend
git worktree list
cd ../myrepo-frontend && git status
cd - && git worktree remove ../myrepo-frontend

git worktree add -b agent/frontend-demo ..\myrepo-frontend
git worktree list
cd ..\myrepo-frontend; git status
cd ..\myrepo; git worktree remove ..\myrepo-frontend

Her worktree'nin kendi HEAD'i, kendi index'i ve kendi dosyaları var. İki süreç iki worktree'de aynı anda düzenleme, build ve test yapabilir; birbirinin yarım kalmış değişikliklerini görmez. Bir agent ekibinin ihtiyaç duyduğu özellik tam olarak bu.

SuperDevSpace bunları nasıl kullanıyor

Kurallar basit ve her organizasyon için aynı:

• Manager ana checkout'unuzda çalışır. Planlar, inceler ve birleştirir; dalların bir araya geldiği tek yer orasıdır.
• Her worker kendi dalında kendi worktree'sini alır. Manager bir worker işe aldığında uygulama onun için git worktree add -b <dal> <yol> çalıştırır. Siz bir ad vermediyseniz dalın adı agent/<worker-adı>-<damga> olur.
• Worktree'ler uygulamanın kendi veri klasöründe, worktrees/<organizasyon>/<worker> altında durur; asla reponuzun içinde değil. Proje klasörünüz agent dizinleriyle dolmaz.
• Her tur commit'lenir. Bir worker bir turu bitirdiğinde uygulama worktree'sinde değişen her şeyi commit'ler (agent(<ad>): turn). Bir worker'ın yaptığı hiçbir şey yalnızca commit'lenmemiş bir çalışma dizininde kalmaz.
• Birleştirme bir squash merge'dür. Manager bir worker'ın raporunu kabul ettiğinde dal, git merge --squash ile tek bir commit olarak sizin hattınıza birleştirilir. Merge çakışırsa uygulama onu iptal eder ve sizi çakışmalı bir merge'ün ortasında bırakmak yerine repoyu bir sonraki işlem için temiz bırakır.
• Repo başına aynı anda tek bir git işlemi. Worktree dizinleri dosyaları ayırır; repo başına bir kuyruk git komutlarının kendisini sıraya koyar. Aynı anda biten iki worker git'in meta verisi üzerinde asla yarışmaz.

Diyagramın metni

gitGraph
  commit id: "main"
  branch agent/frontend
  commit id: "frontend: tur 1"
  checkout main
  branch agent/qa
  commit id: "qa: tur 1"
  checkout agent/frontend
  commit id: "frontend: tur 2"
  checkout main
  merge agent/frontend id: "squash: frontend"
  merge agent/qa id: "squash: qa"

Panoda bu, aynı anda ilerleyen birkaç görev olarak görünür; her biri farklı bir worker'a ait, her birinin altında kendi dalı var.

İşi pratik yapan parçalar

Yeni bir worktree yalnızca git'in takip ettiği dosyaları içerir. Bu genellikle bir projeyi çalıştırmaya yetmez: node_modules, yerel bir .env, üretilmiş dosyalar. Bunu iki ayrıntı çözüyor.

Repo başına bir kurulum betiği

Reponuzda .super/scripts/setup-worktree.sh varsa, uygulama onu worker başlamadan önce her yeni worktree'nin içinde çalıştırır; SUPERDEV_MAIN_REPO ana checkout'unuzu gösterir. Çıktısı canlı akar, yani uzun bir kurulum kör bir bekleyiş değildir ve iptal edebilirsiniz.

#!/usr/bin/env bash
set -euo pipefail
# Yalnızca yerelde duran dosyaları ana checkout'tan kopyala
cp "$SUPERDEV_MAIN_REPO/.env" .env 2>/dev/null || true
# Bağımlılıkları kur (pnpm tek bir paylaşılan depodan bağlar, hızlıdır)
pnpm install --frozen-lockfile

Submodule'ler

git worktree add submodule'leri boş bırakır. Yeni worktree'de bir .gitmodules dosyası varsa uygulama içinde git submodule update --init --recursive çalıştırır; böylece bir worker sessizce eksik kalmış bir bağımlılığa karşı build almaz.

İş kaybetmeden temizlik

Worktree'ler birikir. Uygulama onları geri alır ama bunu temkinli yapar:

Diyagramın metni

flowchart TD
  start["Worker işini bitirdi"] --> clean{"Çalışma ağacı temiz mi?"}
  clean -->|"hayır"| keep["Worktree kalır"]
  clean -->|"evet"| merged{"Dal sizin hattınıza birleşti mi?"}
  merged -->|"hayır"| keep
  merged -->|"evet"| remove["Worktree kaldırılır"]

Commit'lenmemiş değişikliği olan ya da dalında henüz sizin hattınıza girmemiş iş bulunan bir worktree olduğu yerde kalır. Silinmiş bir klasör yeniden oluşturulabilir; kaybolan iş geri gelmez. Aynı temkin dallar için de geçerli: uygulama kendi oluşturduğu dalların kaydını tutar ve yalnızca onlara dokunur.

Sizin için ne değişiyor

Her worker kendi dalında olunca "dört agent'ı aynı anda çalıştır" bir kumar olmaktan çıkar. Şunları yapabilirsiniz:

• manager'a bağımsız görevlere bölünen bir direktif verip worker'ları paralel çalıştırmak;
• herhangi bir worker'ın diff'ini, onu üreten konuşmanın yanında tek başına okumak;
• bir worker'ın değişikliğini diğerlerini bozmadan reddetmek;
• ekip çalışırken ana checkout'unuzu kendiniz kullanmaya devam etmek.

Bu, insan ekiplerinin kullandığı disiplinin aynısı; birbirinin ayağına basmak üzere olduklarını size söyleyemeyen agent'lara uygulanmış hali. Bunun etrafında neden koca bir uygulama yaptığımızı merak ediyorsanız ilk yazımız o hikâyeyi anlatıyor.

Deneyin

14 günlük deneme Premium ve kart gerektirmez. SuperDevSpace'i indirin, yeni bir organizasyonu bir repoya yönlendirin ve manager ilk worker'larını işe alırken worktree'lerin belirişini izleyin.