Copilot oturumunu VS Code'a taşımak: bağlamı kaybetmeden devam etmek

GitHub, Copilot uygulamasında başlatılan bir ajan oturumunun VS Code'a taşınmasını anlatan bir rehber yayımladı (19 Ekim 2026). Bir hafta önceki rehber ise başka bir soruya bakıyor: Copilot'a kod tabanının kurallarını, tekrarlanan iş akışlarını ve dış araçları nasıl tanıtırsınız? İki metin aynı işin iki yarısını tarif ediyor aslında; biri işi ajandan devralmayı, diğeri ajanın ilk turda daha isabetli çalışmasını konu ediniyor.

İlk rehberin çözdüğü sıkıntı tanıdık: Ajan değişikliğin büyük kısmını bitirir, siz ise bir uygulama detayına bakmak, birkaç satırı elle düzeltmek ve projeyi yerelde çalıştırmak istersiniz. O ana kadar üretilen konuşmayı ve değişiklikleri kaybetmeden editöre geçmek mümkün. İkinci rehber ise aynı konuşmayı her seferinde baştan yapmak zorunda kalmamanın yolunu gösteriyor.

Bu iki yeteneği bir arada kullanmak, ajanı hem daha az açıklamayla çalıştırıp hem de sonucu kendi gözünüzle denetlemenizi sağlıyor. Aşağıda önce oturum aktarımının neyi koruduğuna, sonra depoya yazılan bağlam katmanlarına ve en sonunda pratik sınırlara bakıyorum. İki metin de GitHub'ın kendi anlatımı; bağımsız bir ölçüm ya da karşılaştırma sunmuyorlar.

Oturum VS Code'a taşınırken ne korunuyor?

Bir oturum sadece değişmiş dosyaların listesi değil. Görev tanımı, plan ve o değişiklikleri üreten konuşma da oturumun parçası. GitHub'ın aktarım rehberine göre oturumdaki “Open in VS Code” seçeneği, projeyi oturumun kullandığı worktree ile açıyor ve aynı oturumu Copilot kenar çubuğunda gösteriyor. Böylece üç parça birbirine bağlı kalıyor: oturum bağlamı, diff ve izole çalışma ağacı.

Buradaki kritik nokta, yeni bir sohbet penceresi açıp geçmişi özetlemek zorunda olmamanız. “Bu fonksiyonu neden yeni bir yardımcı eklemek yerine değiştirdin?” gibi bir soruyu doğrudan sorabiliyorsunuz, çünkü ajan hangi dosyadan bahsettiğinizi biliyor. Uygulama birden fazla desteklenen editör veya VS Code kurulumu görürse hangisini açacağınızı da siz seçiyorsunuz. Ayrıntılar için GitHub Blog'daki aktarım rehberine bakabilirsiniz.

İnceleme, elle düzenleme ve yerel doğrulama

Editöre geçtikten sonra ilk iş diff'i okumak. Source Control görünümünde dosyaları tek tek açıp ajanın önerdiği değişikliği sıradan bir katkı gibi değerlendirmek gerekiyor: kod istenen sorunu çözüyor mu, depo konvansiyonlarına uyuyor mu, hata durumları ele alınmış mı, değişen davranış test edilmiş mi, ilgisiz dosyalara dokunulmuş mu?

Elle düzenleme adımı özellikle küçük işler için hızlı: bir etiket metnini düzeltmek, değişkeni anlaşılır biçimde yeniden adlandırmak, eksik bir test durumu eklemek. Elle yaptığınız değişiklik ajanın çalıştığı worktree üzerine bindiği için dosya kopyalama veya dal yeniden oluşturma derdi çıkmıyor.

Yerel doğrulamada entegre terminalde deponun normal iş akışı çalıştırılıyor. GitHub'ın örneği web uygulamaları için npm install, npm test, npm run lint ve npm run dev komutlarını veriyor; bunlar evrensel değil, deponuzun kendi betiklerine bakın. Arayüz değişikliklerinde yalnızca istenen davranışı değil, yükleme, boş ve hata durumlarını da farklı ekran genişliklerinde kontrol etmek gerekiyor. Hazır olduğunda commit ve push, oturumun zaten izlediği pull request'i güncelliyor.

Bağlamı depoya yazmak: dört katman

İkinci rehber, Copilot'a kod tabanınızı öğretmenin dört yolunu ayırıyor ve her birini farklı bir ihtiyaca bağlıyor. Hepsinin ortak fikri şu: bilgi depoda durursa her yeni görevde aynı standartları tekrar anlatmanız gerekmez. Rehberin tamamı GitHub Copilot app for Beginners yazısında.

Özel talimatlar depo genelinde geçerli konvansiyonları taşır: mimari tercihleri, adlandırma kuralları, test beklentileri. Depo kökünde .github/copilot-instructions.md dosyası bu işi görüyor. Yol bazlı talimatlar ise .github/instructions altında, applyTo alanıyla hangi dosyalarda geçerli olacağını söylüyor; böylece her dosya türünü aynı kalıba sokmadan geniş kuralları tek yerde tutabiliyorsunuz.

Ajan becerileri yalnızca belirli bir prosedür sırasında anlamlı olan bilgiyi paketliyor. Bir beceri, kendi alt klasöründe duran ve talimatlarla isteğe bağlı betikleri bir arada tutan bir klasör; .github/skills/quality-checks altındaki SKILL.md hangi komutların çalıştığını, neyi kontrol ettiklerini ve yaygın hatalarda ne yapılacağını anlatabiliyor. Özel ajanlar ise erişilebilirlik incelemesi gibi birden fazla dosyaya yayılan işler için ayrı bir rol tanımlıyor; profil .github/agents altında duruyor.

MCP sunucuları bu üçünün dışına çıkıp Copilot'u dış araçlara ve veri kaynaklarına bağlıyor. Rehberdeki örnek Playwright: yapılandırıldıktan sonra Copilot tarayıcıda uygulamayı açıp arayüzle etkileşebiliyor, yani otomatik testlerin kapsamadığı davranışı da deneyebiliyor. Burada dikkat edilmesi gereken nokta, MCP'nin yetki ve erişim sınırlarını ayrıca düşünmeniz gerektiği.

Küçük başlamak için kontrol listesi

• Sürekli tekrar ettiğiniz bir konvansiyonu seçip .github/copilot-instructions.md dosyasına yazın; ilk denemede birkaç kural yeterli.
• Her seferinde aynı sırayla yaptığınız çok adımlı bir işi (test, lint, sürüm hazırlığı) beceri klasörüne taşıyın.
• Birden çok dosyayı gezip farklı araçlar kullanan, tekrar eden bir iş için özel ajan tanımlayın.
• Copilot'un depo dışından bir araca ihtiyaç duyduğu yeri belirleyip yalnızca o araç için MCP sunucusu ekleyin.
• Hazır örnek ararken Awesome Copilot gibi topluluk listelerine bakın, ama içeriği kendi araçlarınıza göre gözden geçirmeden kullanmayın.

Sınırlamalar ve pratik uyarılar

Oturum aktarımı, uygulamanın desteklediği editör kurulumlarına bağlı; listede olmayan bir kurulumda davranış farklı olabilir. Worktree yaklaşımı işi temiz tutuyor ama diskte ek çalışma ağacı ve dal düzeni anlamına geliyor, ekip alışkanlığınızla çakışabilir. Push işleminin mevcut pull request'i güncellemesi de dalın gerçekten o oturuma ait olmasına dayanıyor.

Talimat, beceri ve ajan dosyaları Copilot'un davranışını yönlendirir, garanti etmez; yanlış veya eski bir kural beklediğiniz sonucu vermeyebilir, bu yüzden değişiklikleri sürüm kontrolünde tutup gözden geçirmek gerekiyor. Playwright gibi tarayıcı otomasyonu gerçek kullanıcı akışının yerini tutmaz. Ajanın ürettiği kodu da bir insanın yazdığı gibi ele alın: testleri çalıştırın, hataları okuyun ve davranışı kendiniz doğrulayın.