GitHub Copilot CLI, .NET proje klasöründe copilot komutuyla başlattığınız terminal tabanlı kodlama ajanıdır. Bu rehber; ASP.NET Core, EF Core, xUnit veya NUnit kullanan .NET çözümlerinde ajanı güvenli ve verimli kullanmak için talimat dosyalarını, çalışma döngüsünü ve doğrulama adımlarını anlatır. Genel komut satırı kurulumu için GitHub Copilot CLI sayfasına bakabilirsiniz.
GitHub Copilot CLI neden .NET işlerine uygun?
.NET ekosistemi komut satırından yönetilebilir: dotnet build, dotnet test, dotnet format, dotnet ef gibi komutlar net çıktı üretir. Ajan, CS hata kodlarını, test sonuçlarını ve analyzer uyarılarını okuyup sonraki adımı planlayabilir. Çözüm dosyaları (.sln) ve SDK stilindeki .csproj dosyaları düz metin olduğu için ajan, paket referansı ekleme, proje bağımlılığı düzenleme veya namespace düzeltme gibi işleri satır hassasiyetiyle yapabilir. EF Core migration komutları da terminalde çalıştığı için ajan model değişikliğinden migration oluşturma adımına kadar zinciri sürdürebilir.
Ajan ayrıca çok projeli çözümlerde doğru proje yolunu seçmek için talimat dosyasındaki komutları referans alabilir. Böylece dotnet build çıktısındaki hangi projenin başarısız olduğunu tespit edip sadece ilgili .csproj veya .cs dosyasını düzeltebilir. Minimal API, controller tabanlı API veya gRPC servisleri gibi farklı katmanlarda da çalışabilir; çünkü tüm bu proje türleri aynı dotnet CLI komutlarıyla yönetilir.
Projeyi ajan için hazırlamak
Ajan, proje kökündeki .github/copilot-instructions.md veya AGENTS.md dosyasını okur. .NET çözümü için bu dosyaya build, test ve format komutlarını, klasör düzenini ve çözüme özgü kuralları yazın. Bu, ajanın her seferinde doğru test projesini veya doğru solution dosyasını kullanmasını sağlar.
Dosyayı kısa tutun; onlarca kural ajanın talimatı göz ardı etmesine yol açabilir. Aynı bilgi AGENTS.md olarak da kökte durabilir; iki dosya varsa karışıklık olmaması için yalnızca birini kullanın. Talimat dosyasının ajan tarafından okunduğunu doğrulamak için ilk komutta “Talimat dosyasındaki build ve test komutlarını listele” diyebilirsiniz.
Aşağıdaki örnek, çok projeli bir ASP.NET Core çözümü için başlangıçtır:
# .NET Çözüm Talimatları
## Komutlar
- Build: `dotnet build src/MyApp.sln`
- Test: `dotnet test tests/MyApp.Tests/MyApp.Tests.csproj --no-restore`
- Format kontrol: `dotnet format src/MyApp.sln --verify-no-changes`
## Klasör düzeni
- Üretim kodu `src/`, test projeleri `tests/` altında.
- Her test projesi tek bir .csproj dosyasıdır.
- `obj/` ve `bin/` klasörlerini asla değiştirme veya silme.
## .NET'e özgü kurallar
- Nullable etkin; yeni kodda `null!` veya `#nullable disable` kullanma.
- EF Core sorgularında read-only işlemler için `AsNoTracking` kullan.
- Test sınıfları xUnit ile yazılır; test adları `Method_State_Expected` biçiminde olur.
- Değişiklik sonrası `dotnet build` ve ilgili testleri çalıştır.
- `global.json`, `Directory.Build.props` veya `.editorconfig` dosyalarını değiştirme; bunlar ekip kararıyla güncellenir.
- Yeni kodda file-scoped namespace kullan; eski dosyaları dönüştürme.Bu dosyadaki komutlar, ajanın her görevde aynı test projesini bulmasını ve doğru solution dosyasını kullanmasını sağlar. Ayrıca ajanın dotnet format sonucunu kontrol etmesi, CI ile tutarlılık açısından önemlidir. Kuralların detaylı yazımı için Yapay zekâ ajanlarıyla spec odaklı geliştirme rehberi rehberine bakabilirsiniz.
Çalışma döngüsü: plan, küçük adım, test, diff
.NET projesinde ajanı denetimsiz bırakmak yerine küçük döngüler kurun. Önce değişiklik planını isteyin, sonra tek bir dosyayı veya tek bir hatayı hedefleyen komut verin. Ajan uygulamayı bitirdikten sonra dotnet build ile derleyin, etkilenen testleri çalıştırın ve git diff ile değişiklikleri inceleyin. Özellikle birden fazla projeyi etkileyen refactoring işlerinde diff’e bakmadan ajanın önerisini kabul etmeyin.
Akışı şöyle kurgulayın: ajanı başlatmadan önce mevcut durumu git commit ile kaydedin veya ayrı bir dal açın. İlk komutta ajanın görevi anladığını teyit edin; örneğin “Önce AppDbContext içindeki entity modellerini listele, sonra eksik index önerisi yap.” gibi iki adımlı bir istek, ajanın doğru bağlamı yakalamasına yardım eder. Uygulama adımı bittiğinde önce git status ile değişen dosyaların listesini alın, sonra her dosya için git diff -- <dosya> çıktısını inceleyin. Build hataları varsa, hata mesajlarını ajanın konuşmasına yapıştırıp “bu hataları aynı dosyada düzelt” deyin; böylece ajan tüm projeyi değil, yalnızca hatalı satırları değiştirir.
.NET çözümleri için örnek komutlar:
- “Mevcut
OrderServicesınıfını incele; bağımlılıklarını listele veIOrderRepositoryenjeksiyonuna geçiş için 3 adımlı plan öner.” - “
src/MyApp.Api/Controllers/OrdersController.csiçindekiGetOrderaction metodunaCancellationTokenekle, sadece bu dosyayı ve ilgili arayüzü değiştir.” - “
AppDbContextiçindeOrderItem.OrderIdüzerinde eksik index var mı kontrol et; gerekiyorsa yeni EF Core migration oluştur ama komutu çalıştırma.” - “Çözümde başarısız testleri listele, ilk ikisinin nedenini tespit et ve düzelt; sonra
dotnet testile doğrula.” - “
src/MyApp.CoreprojesineFluentValidationpaketini ekle, sonraCreateOrderRequestiçin validator sınıfı yaz ve mevcut controller’da kullan.”
Bu komutlar tek bir dosyayı veya hatayı hedeflediği için ajanın yanlış katmana dokunma riski azalır. Her döngünün sonunda ajanın ürettiği kodu dotnet format ile kontrol edin ve analyzer uyarılarını gözden geçirin; ajan nadiren #pragma warning disable gibi satırlar ekleyebilir, bunları diff’te yakalayın.
Tipik .NET görevleri ve dikkat edilecek yerler
Ajan; CRUD endpoint’leri, DTO eşleme, xUnit/NUnit test taslakları, EF Core mapping ve migration üretimi gibi tekrarlı işlerde hız kazandırır. Roslyn analyzer uyarılarını temizlerken veya basit refactoring yaparken de işe yarar.
Buna karşılık .NET’e özgü birkaç noktada yakından izlemek gerekir:
| Görev | Ajanın iyi olduğu yön | Dikkat edilecek nokta |
|---|---|---|
| NuGet paket ekleme | Paket adını ve sürümünü .csproj’a doğru yazabilir | Uyumlu sürüm seçimi; yanlış TFM veya binding sorunları oluşabilir |
| EF Core migration | Model değişikliğinden migration dosyası üretebilir | Migration adı, snapshot tutarlılığı ve DbContext seçimi doğrulanmalı |
| Test yazma | xUnit/NUnit test iskeletini hızlı oluşturur | Testin davranışı gerçekten doğruladığından emin olun; boş geçen test üretmesin |
| Nullable ve async | Nullable uyarılarını düzeltebilir | async void, ConfigureAwait(false) veya Task dönüşü gibi noktaları gözden kaçırabilir |
| DI kayıtları | Servis ömrünü (Transient, Scoped, Singleton) doğru önerebilir | Scoped servisi Singleton içinde kullanmak gibi hataları görebilir; kontrol edin |
| Minimal API | MapGet/MapPost tanımlarını hızlı yazar | Route çakışması, validation eksikliği veya [FromBody] kullanımını atlayabilir |
Ayrıca global.json SDK sürümü, Directory.Build.props ve obj/bin klasörleriyle ilgili değişiklikleri ajanın yapmasına izin vermeyin. Çok hedefli projelerde veya InternalsVisibleTo kullanılan çözümlerde ajanın eklediği kod, yanlış target framework’e gidebilir; diff’i mutlaka kontrol edin.
EF Core kullanıyorsanız, ajan sorgu yazarken Include eklemeyi abartabilir veya AsNoTracking kuralını atlayabilir. Migration üretirken dotnet ef migrations add komutunun çıktısını kendiniz de inceleyin; ajanın DbContext veya başlangıç projesi seçimini yanlış yapması ihtimaline karşı --project ve --startup-project parametrelerini talimat dosyasında belirtin.
Test ve doğrulama
Ajan değişiklik yaptıktan sonra önce dotnet build ile derleme hatalarını temizleyin, sonra dotnet test ile etkilenen test projelerini çalıştırın. Tek bir test sınıfına odaklanmak için dotnet test --filter FullyQualifiedName~Orders gibi filtreler kullanın; böylece döngü saniyeler içinde tamamlanır. Ajanın test çıktısını okumasına izin verin, ancak testleri geçirebilmek için üretim kodunu veya testleri zayıflatmasına müsaade etmeyin. Son adımda git diff ile değişiklikleri satır satır inceleyin. Eğer ajan bir testi yanlış geçiriyorsa, testi geri alıp ajanı dar bir komutla yeniden yönlendirin.
Test projesi dışında ajanın ürettiği kodu dotnet format ile de kontrol edin. CI’da aynı komutlar çalışacağı için lokal doğrulamanın CI ile tutarlı olması gerekir; ajanın format kurallarını atlamadığından emin olun. Ek olarak dotnet build -warnaserror komutunu kullanarak uyarıları hata kabul edin; böylece ajanın bastırdığı veya göz ardı ettiği analyzer uyarıları ortaya çıkar. EF Core sorguları için testlerde InMemory provider veya SQLite kullanılabilir; ancak ajanın testi geçirmek için üretim kodunu değiştirmesine izin vermeyin.
Birden fazla ajanı AgentVera ile çalıştırmak
.NET çözümlerinde biri API, biri test projesi üzerinde çalışan iki ajanı aynı klasörde koşturmak dosya çakışması riski taşır. AgentVera, her ajanı kendi gerçek terminal panelinde ve kendi git worktree’sinde çalıştırarak bu riski ortadan kaldırır. Ajanın sırası bittiğinde ikinci bir modelin otomatik kod incelemesi; nullable, EF Core veya test kalitesi sorunlarını file:line ile gösterir. Token bütçeleri ve kontrol noktaları sayesinde ajan kontrolden çıkmadan durur ve hatayı tek tıkla geri alabilirsiniz. Bu, çok projeli .NET çözümleri için paralel çalışmayı güvenli hale getirir.
Sonuç
GitHub Copilot CLI, .NET projelerinde terminal tabanlı çalışmayı seven ekipler için doğru kurallarla çok verimli olur. Proje kökünde copilot komutunu başlatmadan önce talimat dosyanızı netleştirin; her değişikliği derleme, test ve diff ile doğrulayın. Daha geniş bir komut rehberi için GitHub Copilot CLI nasıl kullanılır? Adım adım rehber adresine göz atabilirsiniz.