Laravel Geliştiricileri için Git Worktrees: Paralel Olarak Birden Fazla Claude Kod Oturumu Çalıştırma

Orijinal makale: hafiz.dev

Bir Claude Code oturumunda derinleşmiş durumdasınız. Yirmi dakika boyunca gidip geliyor ve şimdiye kadar tüm karmaşıklıkları anlamış durumda. Üç dosya açık ve düzenleme aşamasındasınız. Birden telefonunuz titreşim yapıyor. Kendi sitenizde bir hata var.

Peki ne yapıyorsunuz?

Değişikliklerinizi saklarsanız ve dallar arasında geçiş yaparsanız, Claude’un bağlamını kaybedersiniz. Ana dalda yeni bir oturum başlatmak, kod tabanını her seferinde sıfırdan açıklamak demektir. İkinci bir terminal açıp aynı dosyalarda farklı bir dalda çalışmaya çalışmak ise sorun çıkarır. Taahhüt edilmemiş değişiklikler çakışır. Migrations birbirine karışır. Herd siteniz yanlış dalı sunar. Eğer kuyruk işleyicileri veya Vite geliştirme sunucusu çalıştırıyorsanız, hangi sürecin hangi dal ile ilişkili olduğunu takip etmekte zorlanırsınız.

Bu durum, Claude Code’u günlük çalışmanız olarak kullanmaya başladığınızda sürekli karşılaştığınız bir problemdir. Bir müşteri özelliği, kendi projeniz için acil bir düzeltme veya üretim öncesi kodu etkilemeden gerçekleştirmek istediğiniz bir deney. Paylaşımlı çalışma dizini modeli, gerçek anlamda çalışmayı paralel hale getirdiğinizde ölçeklendirmez.

Bu sorun, git worktrees’lerin çözdüğü bir mesele. Şimdi Claude Code’un yerel worktree desteği ile entegre olduğu için bu iş akışını kullanmamak için gerçekten bir sebep yok. Sizin için bir Laravel projesi üzerinde nasıl kurulacağını göstereceğim çünkü genel kılavuzlar, Laravel’e özgü kısımları atlıyor.

Git Worktree Nedir?

Çoğu geliştirici yıllardır git kullanıyordur, ancak hiç worktree ile tanışmamıştır. Zihinsel model, bunu gördüğünüzde basittir.

Normalde, git havuzunuzun tek bir çalışma dizini vardır. Her dal, disk üzerindeki aynı dosya setinde yaşar. Dalları değiştirdiğinizde dosyalarınız değişir. Git bu şekilde çalışır.

Bir worktree, aynı havuzla bağlantılı ikinci (ya da üçüncü, dördüncü) bir çalışma dizinidir. Her worktree kendi dalına ve bağımsız dosyalarına sahiptir. Ancak tümü aynı git geçmişini, aynı nesneleri ve aynı uzakları paylaşır. Bir worktree içinde taahhüt ettiğinizde, o taahhüt, diğer tüm worktree’lerde hemen kullanılabilir.

# Ana projeniz
/projects/my-app/        ← ana dal, temel Claude oturumunuz

# Bağlı bir worktree
/projects/my-app/.claude/worktrees/feature-billing/  ← feature/billing dalı, ikinci Claude oturumu

Her iki dizin de aynı kod tabanına sahiptir. Farklı dallar. Tamamen bağımsız dosyalar. Her ikisini aynı anda çalıştırabilirsiniz.

Bu yeni bir özellik değil. Git, 2015’ten beri worktree’lere sahip. Değişen, Claude Code’un bunları yerel olarak desteklemesi oldu ki bu da izole bir AI oturumu başlatmayı tek komutla gerçekleştiriyor.

Claude Code için Neden Önemli?

Burada çoğu kişinin atladığı bir nokta var: oturum sırasında dalları değiştirmek, yalnızca dosyalarınızı bozmaz. Aynı zamanda AI’nın bağlamını da bozar.

Claude Code, bir oturum süresince kod tabanınızı anlamaya çalışır. Dosyalarınızı okur, açıklayıcı sorular sorar, kalıplarınızı çözer. Bu bağlam, konuşmadan yaşar. Değişikliklerinizi sakladığınızda, dalları değiştirdiğinizde ve yeni bir göreve başladığınızda, o birikmiş bilgi gitti. Yeniden sıfırdan başlamanız gerekir.

Worktree’ler, bu durumu dosya sistemi düzeyinde çözer. Her oturum kendi dizininde, kendi dalında kalır. Claude, hangi dosyaların hangi görevle ilişkili olduğunu karıştırmaz. Farklı bir dalda yalnızca bulunana bir migration’ı okumaya çalışmaz. Henüz tamamlanmamış bir özellikten kalma yarım kodu görmez. Gördüğü her şey, çalıştığı oturum için geçerlidir.

Bu durum, karmaşık bir Laravel uygulaması için oldukça önemlidir. Servis sağlayıcıları, olay dinleyicileri, Eloquent ilişkileri, özel artisan komutları. Claude Code, bunların haritasını oluşturur. Bu harita, baktığı kod tabanının durumuna özgüdür. Temiz, izole bir ortam sağlarsanız, harita doğru kalır.

Bu, uygulamanızı gerçekten AI-agent dostu hale getirmenin bir parçası ile doğrudan bağlantılıdır. Bir ajan, karışıklıklardan düzeltme yapmadan daha az zaman harcayabilir. Bir worktree, varsayılan olarak temiz bir ortamdır.

Laravel’e Özgü Sorun

Ham bir git worktree add işlemi size dosyaları verir. Hepsi bu. Vanilla JavaScript projesi için yeterli olabilir.

Bir Laravel projesi için çok daha fazlasına ihtiyacınız var:

• Ayrı bir veritabanı (bu nedenle A dalındaki migrations, B dalını bozmasın)
• Ayrı bir .env dosyası, doğru APP_URL, DB_DATABASE, ve SESSION_DOMAIN ile
• Aynı anda her iki dalı da tarayıcıda açabilmenize imkan tanıyan ayrı bir Herd sitesi
• İki projenin çakışmaması için farklı bir portta Vite geliştirme sunucusu

Hiçbir genel git worktree kılavuzunda bu bölümler yer almıyor. Her birini adım adım inceleyelim.

Laravel Worktree’yi Doğru Bir Şekilde Kurma

Adım 1: Worktree’yi Oluşturun

Proje kök dizininizden:

git worktree add .claude/worktrees/feature-billing -b feature/billing

Bu, .claude/worktrees/feature-billing/ dizininde yeni bir dizin oluşturur ve feature/billing adlı yeni bir dalda kontrol edilir. Şu anda .claude/worktrees/ yolunu .gitignore dosyanıza ekleyin, böylece git bu dizinleri izlemeye çalışmaz.

echo ".claude/worktrees/" >> .gitignore

Adım 2: Ayrı Bir Veritabanı Oluşturun

Bu adım genellikle atlanır ve ardından herkes neden migrations’ın bozulduğunu anlamaya çalışır.

mysql -u root -e "CREATE DATABASE myapp_billing;"

Her worktree’nin kendi veritabanına ihtiyacı vardır. Paylaşılan veritabanları gerçekte problemler yaratır. Bir dalda bir sütun ekleyen bir migration varsa diğer dal bundan haberdar değildir. Testleriniz kodunuzla hiçbir ilgisi olmayan şekillerde başarısız olmaya başlar. Worktree’ler arasında veritabanı paylaşmayın.

Adım 3: Worktree’nin .env Dosyasını Yapılandırın

Worktree dizinine girin ve ana .env dosyanızı kopyalayın:

cd .claude/worktrees/feature-billing
cp ../../.env .env

Sonra yeni .env dosyanızdaki üç şeyi güncelleyin:

APP_URL=http://myapp-billing.test
DB_DATABASE=myapp_billing
SESSION_DOMAIN=myapp-billing.test

Eğer Sanctum kullanıyorsanız, SANCTUM_STATEFUL_DOMAINS ayarını da yeni alan adıyla eşleşecek şekilde güncelleyin.

Adım 4: Worktree’yi Laravel Herd ile Kaydedin

Worktree dizininde:

herd link myapp-billing

Bu işlem, dizini http://myapp-billing.test adresinde bir Herd sitesi olarak kaydeder. Artık ana dalınızı ve özellik dalınızı yan yana tarayıcıda açabilirsiniz. Tamamen bağımsızdırlar.

Adım 5: Migrations’ı Çalıştırın ve Bağımlılıkları Kurun

php artisan migrate
composer install
npm install

Her worktree için ayrı vendor/ ve node_modules/ dizinleri gereklidir. Bağımlılıklar paylaşılmaz.

Adım 6: Vite’i Farklı Bir Portta Başlatın

Worktree’deki vite.config.js dosyasını güncelleyerek farklı bir geliştirme sunucu portu kullanın veya çalışma zamanı sırasında portu geçerek ayarlayın:

npm run dev -- --port 5174

Ana projeniz muhtemelen 5173‘te çalışıyor. Farklı bir port seçin. Bu, iki Vite örneğinin çakışmasını önler.

Adım 7: Claude’u Başlatın

claude

Artık tamamen izole bir Laravel ortamınız var. Kendi dalı, kendi veritabanı, kendi Herd alanı, kendi Vite sunucusu ve kendi Claude oturumu.

Daha Hızlı Yol: Yerel Claude Code Worktree Desteği

Claude Code v2.1.49 (19 Şubat 2026’da yayınlandı) yerel worktree desteğini --worktree bayrağı ile ekledi. Manuel git worktree add adımını tamamen atlayabilirsiniz:

# Proje kök dizininden
claude --worktree feature-billing

Bu, .claude/worktrees/feature-billing/ dizinini oluşturur, worktree-feature-billing adında yeni bir dalı kontrol eder ve o dizine özgü bir Claude oturumu açar. Hepsi tek bir komutla.

Ayrıca, bir kısayol da var:

claude -w feature-billing

Ve yan yana terminal panelleri için tmux entegrasyonu isterseniz:

claude --worktree feature-billing --tmux

--tmux bayrağı, aynı terminal penceresinde bir Claude paneli ve bir shell paneli verir. Artisan komutlarını çalıştırmak ve Claude oturumunuzla birlikte yan yana kullanmak için yararlıdır.

Bir önemli not: Yerel bayrak, git ayarını otomatik olarak halleder, ancak Laravel ortamınızı bilmez. Laravel uygulamanızın gerçekten çalışması için, veritabanını oluşturmanız, .env dosyasını güncellemeniz ve migrations’ı çalıştırmanız gerekir. Git izolasyonu otomatik, Laravel izolasyonu ise sizin işiniz.

--worktree ile başlatılan bir oturumdan çıktığınızda, Claude sizden worktree’yi tutup tutmayacağınızı sorar. Değişiklik yapmadıysanız otomatik olarak temizler. Eğer taahhütleriniz varsa, bunu sorar. Bu temizlik davranışı gerçekten hoş. Eski worktree’lerden oluşan bir mezarlıkla karşılaşmazsınız.

İşe Yarayan Worktree İsimlendirme Konvansiyonları

Hiç kimse bunu konuşmuyor ama bir worktree’ye verdiğiniz ad göründüğünden daha önemlidir. Birden fazla terminal açık olacak. Onlar arasında geçiş yapacaksınız. Kötü bir isimlendirme şeması, hangi terminalin hangisi olduğuna sürekli bakmanıza neden olur.

Uygulamada işe yarayan birkaç konvansiyon:

Çalışma türünü belirten bir önek kullanın. feature-, hotfix-, experiment-, refactor- gibi önekler, hemen hangi tür oturum olduğunu anlamanızı sağlar.

claude -w feature-stripe-webhooks
claude -w hotfix-login-redirect
claude -w experiment-redis-cache

İsimleri kısa ama spesifik tutun. feature-billing iyi. feature-billing-invoice-pdf-generation-fix değil. Sürekli yazacağınız ya da tamamlama yapacağınız bir şey. Öneklerden sonra iki veya üç kelime yeterlidir.

Worktree adını, nihayetinde PR için açacağınız dal adıyla eşleştirin. Claude, --worktree feature-billing ile worktree oluşturduğunda, dal adını worktree-feature-billing olarak belirler. Eğer worktree’leri manuel olarak git worktree add ile oluşturuyorsanız, aynı ismi talep edilen PR dalı ile kullanın ki sonradan gözden geçirdiğiniz diff, planladığınız değişikliklere temiz bir şekilde eşleşsin.

Deneylerde açık olun. Eğer çalışmanın gönderilip gönderilmeyeceğinden emin değilseniz, bunu experiment- olarak adlandırın. Geri döndüğünüzde doğru beklentileri belirlemek için önemlidir. Sonunda değişikliği herhangi bir diff checker ile gözden geçirdiğinizde, iyi isimlendirilmiş bir worktree neyi kanıtlamak istediğinizi hatırlatır.

Küçük bir şey. Ama üç paralel oturum yönettiğinizde gerçekten sürtünmeyi azaltır.

Worktree’ler Ne Zaman Aşırı Olur?

Bunu dürüstçe belirtmek istiyorum çünkü tüm durumlar worktree gerektirmiyor.

Tek bir proje üzerinde çalışan bir solo geliştiriciyseniz ve paralel görevler yoksa, buna ihtiyacınız yok. İkinci bir veritabanı ve Herd sitesi kurmanın getirdiği yük gerçekten önemlidir ve eğer paralel oturumlar gerçekleştirmiyorsanız bu artıracak herhangi bir şey yoktur.

Hızlı hata düzeltmelerinin de worktree’lere ihtiyacı yoktur. Beş dakikada düzeltebileceğiniz bir şeyse, mevcut çalışmanızı kaydedip yapılandırmak istemiyorsanız, bunu yapmalısınız. Worktree’ler, gerçekten paralel iş parçacıklarını yürüttüğünüz durumlar içindir.

Ayrıca, bağlam penceresi yönetimi konusunda geçerli bir endişe var. Üç Claude Code oturumu çalıştırmak, üç konuşma boyunca token tüketmeyi gerektirir. Eğer sınırlı bir planınız varsa, hangi oturumların gerçekten aktif olduğunu ve hangilerinin sadece bekleyen oturumlar olduğunu dikkatlice planlayın.

Burada tanımladığım model, Üretim Uygulamalarınızı Vibe Kodlamayı Durdurun ile de geçerli: worktree’ler, AI’nın aynı anda birden çok özellik üzerinde denetimsiz çalışmasını sağlamak için değildir. Hala inceleme ve yönlendirme işini yapıyorsunuz. Paralellik, bağlam değiştirmeye yardımcı olur. Yargının yerini alamaz.

Eğer Claude Code iş akışınızın gerçekten üretken olmasını istiyorsanız, Laravel Beceri Dizinine göz atabilirsiniz; bu, özellikle tekrar eden görevlerde, araç oluşturmak veya dallar arasında migrations çalıştırmak gibi reusable ajan becerilerini Sunucu kurulumlarıyla birlikte iyi bir şekilde kullanmaktadır.

SSS

Her worktree’nin kendi vendor/ ve node_modules/ dizinleri olmalı mı?

Evet. Worktree’ler bağımlılıkları paylaşmaz. Yeni bir worktree oluşturduğunuzda, Laravel uygulamanızın çalışması için içerisinde composer install ve npm install komutlarını çalıştırmalısınız. Bu, kurulum süresini artırır, ancak dallar arasındaki sürüm çakışmalarını önler.

Aynı Redis örneğini worktree’ler arasında kullanabilir miyim?

Kullandığınız Redis’e bağlı. Kuyruk işleyicileri ve önbellek genellikle farklı önekler kullanıyorsanız paylaşmaya uygundur. Oturumlar ise daha karmaşık. Her iki worktree aynı anda çalışıyorsa ve bir oturum deposunu paylaşıyorsanız, karışıklık olabilir. En güvenli yaklaşım, .env dosyanızda her worktree için farklı bir REDIS_PREFIX yapılandırmaktır.

Ana proje dizinini silersem worktree’lerime ne olur?

Worktree’ler, ana havuza bağlıdır. Ana .git dizinini veya ana projeyi silerseniz, worktree’ler yersiz kalır ve düzgün çalışmaz. Bir projeyi kaldırmadan önce worktree’leri temizlemelisiniz: git worktree list ile aktif olanları görün, ardından her biri için git worktree remove yapın.

Her worktree’de tam CLAUDE.md dosyasını ayarlamak zorunda mıyım?

Hayır. CLAUDE.md dosyası, havuzunuzda saklanır ve her worktree’de kodunuzla birlikte kontrol edilir. Eğer proje-specific talimatlarınız varsa, bu her worktree’de otomatik olarak mevcut olacaktır. CLAUDE.md dosyanızı iyi bir biçimde güncel tutmak, her oturum ve her worktree için fayda sağlar.

Aynı test ortamında entegre testler için A dalı ve B dalını çalıştırabilir miyim?

Çalıştırabilirsiniz, ancak bunun aktif geliştirme için tavsiye edilmediğini belirtmek isterim. Worktree’lerin sunduğu değerin izolasyon olduğunu düşünün. Veritabanı paylaşmak, önlem almaktaki sorunları yeniden ortaya çıkarır. Geliştirme sırasında ayrı veritabanları kullanın ve yalnızca paylaşımlı altyapıyı doğru bir test ortamında test edin.

Git worktree’ler yeni bir hile değil. Yıllardır git’te varlar ve çoğu geliştirici için gereksiz kalmıştır. Ancak Claude Code denklemi değiştirdi. AI ajanın, kod tabanınız hakkında gerçek bir bağlam inşa etmesi gerektiğinde, ona özel bir ortam sağlamak bir lüks değil, sadece iyi bir uygulamadır.

Laravel’e özgü kurulum, ilk seferde yaklaşık on dakika sürer. Sonrasında hızlıdır. Ve birden fazla oturumu tek bir saklama veya birleştirme çakışması olmadan çalıştırdıysanız, bir daha geriye dönmeyeceksiniz.

AI destekli özellikler geliştiriyorsanız ve mimariyi tartışmak istiyorsanız, bize ulaşın.