AI Destekli Yazılım Geliştirmede Git Worktree ve Merge Queue

AI destekli yazılım geliştirme için paralel çalışma sınırı

Bir generative ai ajanına doğrudan geliştiricinin çalışma dizinini vermek, yalnızca dosya çakışması yaratmaz; aynı .git/index, geçici build çıktıları ve çalışma ağacındaki izlenmeyen dosyalar da ajanlar arasında görünür hale gelir. Her görev için origin/main'in sabit bir commit'inden ayrı worktree üretin ve ajanın yalnızca kendi dalına yazmasına izin verin. Bu modelde ajan A'nın package-lock.json değişikliği, ajan B'nin diff'ine sızmaz.

git fetch origin main
TASK=payments-timeout
BASE=$(git rev-parse origin/main)
git worktree add --detach ../agent-$TASK $BASE
cd ../agent-$TASK
git switch -c agent/$TASK
printf '%s\n' $BASE > .agent-base-sha
git status --porcelain

Görev tamamlandığında merge isteğini oluşturmadan önce tabanın kaymadığını denetleyin. Bu denetim, LLM'in eski bir API imzasına göre yaptığı doğru görünen ancak artık derlenmeyen değişiklikleri erken yakalar. Ajanın yeniden tabanlama yapmasına otomatik izin vermeyin: rebase sırasında ortaya çıkan çatışmayı çözmek, modelin iki bağımsız değişikliğin anlamsal önceliğini tahmin etmesini gerektirir. Bunun yerine çatışmayı insan incelemesine veya yeni bir göreve aktarın.

BASE=$(cat .agent-base-sha)
CURRENT=$(git rev-parse origin/main)
[ $BASE = $CURRENT ] || {
  echo 'base moved: regenerate patch against current main'
  exit 42
}
git diff --check $BASE...HEAD
git diff --name-only $BASE...HEAD

Sık atlanan ayrıntı şudur: worktree'ler Git nesne veritabanını paylaşır. Ajan süreçleri aynı anda git gc veya referans temizliği çalıştırırsa kilit beklemeleri oluşabilir. Ajan konteynerinde bakım işlemlerini kapatın, merkezi bare clone üzerinde ise yalnızca zamanlanmış bakım çalıştırın: git config maintenance.auto false. Kilit gecikmesini somut olarak görmek için bir deneme koşusunda GIT_TRACE2_PERF=/tmp/git-trace.json git status çalıştırın; trace içinde index ve ref lock bekleme sürelerini ayrı ayrı inceleyin.

Vibe coding eğitimi içinde görev sözleşmesi ve dosya sınırı

vibe coding eğitimi veya vibe coding kursu tasarlarken ajana verilen görevi sadece doğal dil talimatı olarak bırakmayın. Depoya makine tarafından doğrulanabilir bir görev sözleşmesi ekleyin. Örneğin ödeme zaman aşımı değişikliğinin yalnızca src/payments ve test/payments altında kalacağını, en fazla 12 dosyaya dokunacağını ve yeni ağ bağımlılığı eklemeyeceğini JSON ile tanımlayın. Bu yaklaşım, modelin kapsam dışı refactor yapmasını merge aşamasından önce engeller.

{
  "task": "payments-timeout",
  "base": "origin/main",
  "allow_globs": ["src/payments/**", "test/payments/**"],
  "deny_globs": [".github/**", "infra/**", "**/package-lock.json"],
  "max_changed_files": 12,
  "required_commands": ["npm test -- payments", "npm run lint"]
}

Sözleşmeyi prompt'a yazmak yeterli değildir, çünkü prompt davranış beklentisidir; CI ise karar noktasıdır. Node.js tabanlı bir doğrulayıcıyla merge isteğinin gerçek diff'ini kontrol edin. Özellikle rename işlemlerinde Git iki yol raporlayabilir; yalnızca yeni yolu denetleyen betik, yasaklı bir dosyanın taşınarak değiştirilmesini kaçırabilir. Bu nedenle --name-status -M çıktısındaki hem eski hem yeni yolu değerlendirin.

node -e '
const {execFileSync}=require("node:child_process");
const out=execFileSync("git",["diff","--name-status","-M","origin/main...HEAD"],{encoding:"utf8"});
const paths=out.trim().split("\n").flatMap(x=>x.split("\t").slice(1));
if (paths.some(p=>p.startsWith("infra/") || p.startsWith(".github/"))) process.exit(2);
if ([...new Set(paths)].length > 12) process.exit(3);
'

Bu pratik, yapay zeka eğitimi, yapay zeka kursu ve llm eğitimi programlarında özellikle önemlidir: modelin ürettiği patch'i değerlendirme nesnesi yapar, model açıklamasını değil. İnceleme ekranında git range-diff origin/main...agent/payments-timeout çıktısını saklamak da yeniden üretim için yararlıdır; squash sonrası kaybolabilecek ara commit niyetini gösterir.

CI CD pipeline içinde merge queue ile gerçek birleşim testi

Her pull request yeşilken main dalının kırılması, testlerin her dalı ana daldan ayrı doğrulamasından kaynaklanır. Merge queue, sıradaki değişikliği güncel ana dal ve kuyruktaki önceki değişikliklerle geçici bir birleşim commit'inde test eder. Bu nedenle gerekli durum kontrolü pull_request ve merge_group olaylarında aynı job adıyla çalışmalıdır; yalnızca pull_request tetikleyicisi tanımlanırsa kuyruk bekleyen bir kontrolü asla tamamlayamaz.

name: verify
on:
  pull_request:
    branches: [main]
  merge_group:
    branches: [main]
concurrency:
  group: verify-${{ github.event.merge_group.head_sha || github.sha }}
  cancel-in-progress: false
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
      - run: git diff --check HEAD^ HEAD

Ajan token'ını merge queue'ya yazma yetkisi olan kalıcı bir erişim anahtarı yapmayın. Ajan yalnızca dalına push edebilen, kısa ömürlü bir kimlik ile çalışmalı; merge yetkisi kuyruk hizmetinde kalmalıdır. GitHub Actions gibi OIDC destekleyen bir çalıştırıcıda bulut rolü için subject koşulunu depo ve dal ile daraltın. Böylece ajan prompt'unda zararlı bir komut üretilse bile ana dala force-push yapabilecek bir kimlik elde edemez.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"},
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {"StringLike": {"token.actions.githubusercontent.com:sub": "repo:acme/payments:ref:refs/heads/agent/*"}}
  }]
}

Merge queue gecikmesini sadece toplam CI süresiyle ölçmeyin. Kuyruğa giriş zamanı, birleşim adayı oluşturulma zamanı ve tamamlanma zamanını üç ayrı alan olarak kaydedin. Kuyruk beklemesi arttığında ilk şüpheli test süresi değil paralellik kotası, aynı concurrency grubunda seri hale gelen işler veya dış bağımlılık limitidir. Bu ayrım, devops eğitimi kapsamında incident analizi için doğrudan kullanılabilecek bir metrik sözleşmesidir.

Ajan throughput'u için profiling, önce-sonra karşılaştırması

Paralel worktree sayısını artırmadan önce darboğazı profilleyin. CI çalıştırıcısında OpenTelemetry ile fetch, bağımlılık kurulumu, test ve artifact yükleme span'ları üretin; Git tarafında Trace2 verisini toplayın. Başlangıç ölçümünü en az 30 benzer merge isteğinde alın: p50 ve p95 queue_wait_seconds, verify_duration_seconds ve git_index_lock_seconds değerlerini ayrı raporlayın. Sonra yalnızca tek değişkeni değiştirin, örneğin ajan sayısını 2'den 4'e çıkarın; aynı test paketi ve aynı çalıştırıcı sınıfıyla tekrar ölçün.

import time
from opentelemetry import trace
meter = trace.get_tracer("merge-verify")
with meter.start_as_current_span("dependency-install") as span:
    started = time.monotonic()
    # subprocess.run(["npm", "ci"], check=True)
    span.set_attribute("ci.phase", "install")
    span.set_attribute("ci.elapsed_ms", (time.monotonic() - started) * 1000)

Örneğin p95 doğrulama süresi 11 dakikadan 10 dakikaya inerken p95 kuyruk beklemesi 4 dakikadan 19 dakikaya çıkıyorsa, dört ajan toplam teslim süresini iyileştirmemiştir. Bu durumda test shard sayısını artırmadan önce concurrency anahtarını kontrol edin. concurrency.group: deploy-production gibi tüm doğrulamaları tek gruba bağlayan bir ayar, koşuları istemeden seri hale getirir. Doğrulama için commit SHA tabanlı, dağıtım için ortam tabanlı ayrı grup kullanın.

concurrency:
  group: verify-${{ github.sha }}
  cancel-in-progress: true
# production deployment workflow'unda ayrı tanım:
# group: deploy-production
# cancel-in-progress: false

Bu ölçüm disiplini yazılım eğitimi ve teknoloji eğitimi açısından da değerlidir: hız iddiasını dashboard'da doğrulanabilir bir hipoteze çevirir. Sık görülen edge case, cache hit oranı yükselirken cache indirme süresinin büyük artifact'lar nedeniyle test süresini geçmesidir. Her cache için hit/miss yanında download byte ve restore duration etiketlerini kaydedin; aksi halde sadece hit oranı yanlış optimizasyon kararı doğurur.

Cloud native mimari laboratuvarında güvenli ajan akışı

Bu akışı yerelde yeniden üretmek için docker eğitimi, kubernetes eğitimi ve minikube laboratuvarını tek bir değişiklik zincirine bağlayın: ajan bir uygulama patch'i üretir, imaj yerelde derlenir, geçici namespace'e dağıtılır ve smoke test sonucu merge isteğine yazılır. Bu, container orchestration davranışını yalnızca YAML okumaktan daha gerçekçi biçimde gösterir; örneğin readiness probe başarısızsa Service endpoint'i oluşmaz ve testin neden bağlantı kuramadığı görülebilir.

minikube start --cpus=4 --memory=6144
minikube image build -t payments:agent-42 .
kubectl create namespace pr-42
kubectl -n pr-42 apply -f k8s/
kubectl -n pr-42 rollout status deploy/payments --timeout=90s
kubectl -n pr-42 run probe --rm -i --restart=Never --image=curlimages/curl -- curl -fsS http://payments/health

Altyapı değişikliklerinde terraform plan dosyasını CI dışında yeniden üretmeyin. Aynı provider sürümü ve aynı değişkenlerle terraform plan -out=tfplan üretip ardından tam o ikili planı terraform show -json tfplan ile değerlendirin. infrastructure as code pratiğinde bu fark kritiktir: plan ile apply arasında sağlayıcı verisi veya uzak durum değişirse ikinci bir plan farklı kaynakları hedefleyebilir. Ayrıcalıkları yalnızca planın kapsadığı workspace ile sınırlayın.

terraform init -lockfile=readonly
terraform plan -out=tfplan -var-file=env/pr-42.tfvars
terraform show -json tfplan > tfplan.json
jq -e '.resource_changes[] | select(.change.actions | index("delete"))' tfplan.json && exit 20 || true

aws eğitimi ve google cloud eğitimi bağlamında aynı kural geçerlidir: CI'nin OIDC kimliği ortam başına ayrı rol veya service account almalıdır, ortak yönetici anahtarı almamalıdır. cloud native mimari laboratuvarını tamamlayan ekip, bu komutları bir ci cd pipeline içinde koşarak uygulama patch'i, imaj etiketi, Kubernetes rollout'u ve Terraform planı arasındaki izlenebilirliği test edebilir.

Sık Sorulan Sorular

ai destekli yazılım geliştirme için Git worktree ne zaman ayrı clone'dan daha uygundur?

Aynı commit nesnelerini paylaşarak disk ve fetch maliyetini azaltmak istediğiniz, fakat her ajanın ayrı çalışma ağacına ihtiyacı olduğu durumda worktree uygundur. Ajanın git gc çalıştırmasını kapatın ve her görevde sabit base SHA kaydedin. Farklı Git credential veya tamamen farklı hook yapılandırması gerekiyorsa ayrı clone daha güvenli bir izolasyon sınırıdır.

ci cd pipeline içinde merge queue testleri neden pull request testlerinden farklıdır?

Pull request testi dalı çoğunlukla origin/main ile tek başına birleştirerek doğrular. Merge queue ise sıradaki diğer değişiklikleri de içeren geçici birleşim commit'ini test eder. Workflow'da merge_group tetikleyicisini ekleyin ve branch protection'ın beklediği test job adını iki olayda da sabit tutun.

vibe coding kursu projelerinde ajanların kapsam dışı dosya değiştirmesi nasıl engellenir?

Prompt kuralının yanına CI diff denetimi koyun. git diff --name-status -M ile rename dahil tüm eski ve yeni yolları alın, allowlist ve denylist'e karşı kontrol edin, maksimum dosya sayısını aşınca işi başarısız yapın. package lock, CI workflow ve infrastructure dizinlerini varsayılan olarak denylist'e koymak iyi bir başlangıçtır.

terraform ve Kubernetes kullanan bir yapay zeka eğitimi laboratuvarı nasıl ölçülür?

Terraform için plan süresi, resource_changes sayısı ve delete aksiyonu sayısını; Kubernetes için rollout süresi, readiness başarısızlığı ve smoke test hata oranını kaydedin. Ajan throughput'u için ayrıca queue_wait_seconds ile verify_duration_seconds histogramlarını p95 olarak önce ve sonra karşılaştırın.