GitHub Copilot App’te Stacked Sessions ve Stacked PR’lar
GitHub Copilot uygulaması, uzun süredir bakımını erteleyen geliştiriciler için yeni bir çalışma düzeni sunuyor: aynı depo üzerinde birbirinin üzerine yığılan oturumlar (stacked sessions) ve bu oturumlardan üretilen zincirleme pull request’ler (stacked pull requests). GitHub Blog’da Cassidy Williams’ın kaleme aldığı yazı, on yılı aşkın bir kişisel projenin modernizasyonunu bu iki kavram üzerinden anlatıyor ve özelliğin pratikte ne işe yaradığını gösteriyor.
Stacked session ve stacked pull request nedir?
Yazının çerçevelediği tanıma göre bir “stack”, aynı depo içinde her pull request’in bir altındaki pull request’in dalını hedeflediği sıralı bir zincir. Zincirin sonunda değişiklikler nihai olarak main dalına iniyor. Stacked sessions ise aynı mantığın Copilot oturumları için uygulanmış hali: Bir oturum, önceki oturumun bağlamını ve değişikliklerini devralarak devam ediyor. Böylece ilgili ama ayrı tutulması gereken işler, tek bir devasa PR’a sıkıştırılmak yerine sıralı ve incelenebilir parçalara bölünebiliyor.
Yazıdaki modernizasyon senaryosu
Williams, 2014 sonlarında başladığı kişisel bir “life dashboard” uygulamasını modernleştirme sürecini adım adım paylaşıyor. Projede React 15, CSS ön-işlemcisi olarak Less ve o dönemin react-bootstrap sürümü kullanılıyor. Yazara göre bağımlılıklar oldukça eskimiş, daha önce yapılan modernizasyon denemeleri de yarım kalmış.
Süreç, Copilot uygulamasına deponun eklenmesi ve Plan modunda bir istem yazılmasıyla başlıyor. İstemde stil katmanının Tailwind ya da vanilla CSS’e taşınması, Less’ten kurtulunması, erişilebilirlik ve responsive iyileştirmeleri, ardından React tarafının kademeli olarak toparlanması isteniyor. Buna ek olarak link davranışları, input alanlarının kenar yuvarlaklığı ve container genişlik sınırları gibi somut kurallar da tarif ediliyor.
Plan aşamasında Claude Opus 4.8’in yanı sıra “rubber duck” incelemesi için GPT-5.5 kullanıldığı belirtiliyor. Yazar, ilk denemede tek seferde çözüme ulaşamadığını anlatıyor; sebep, aktif kullandığı sürümün main değil yarım kalmış bir dev dalı olmasıymış. Bu noktada Copilot uygulamasına yeni bir oturum açtırıp açılan pull request’i kapattırıyor ve stil kararlarını dev dalına uygulanacak değişikliklere taşıtıyor.
Kapsam kaymasını yığın ile yönetmek
Testler sırasında yazar, konsolda findDOMNode ve componentWillReceiveProps gibi eski React uyarılarını görüyor. Bu referansların artık kendi kodunda değil react-bootstrap içinde olduğunu tespit edip yeniden Plan moduna dönüyor ve kütüphanenin yükseltilmesi mi yoksa tamamen kaldırılıp modern bir alternatifle değiştirilmesi mi gerektiğini soruyor. Çıkan öneri, kütüphanenin tümüyle değiştirilmesi yönünde.
Ancak bu iş, mevcut stil çalışması için ciddi bir kapsam kayması demek. Yazının altını çizdiği gözlem şu: Agent tabanlı çalışmada, kodu bizzat yazmadığımız için “her şeyi tek seferde çözelim” cazibesi güçleniyor ve bu da yeni bir erteleme biçimine dönüşebiliyor. Çözüm olarak yazar, tek bir dev PR yerine işleri iki ayrı ama zincirli PR’a bölmeyi tercih ediyor. Copilot’a verdiği istemde şunları istiyor: mevcut çalışma için bir pull request açılması, react-bootstrap değişiklikleri için yeni bir oturumun mevcut çalışmanın üzerinden dallanması ve sonrasında dev‘e merge edilecek ayrı bir pull request oluşturulması.
Yığının somut çıktısı
Yazara göre süreç sonunda Copilot uygulaması şu adımları gerçekleştiriyor:
- Mevcut değişiklikler için
devdalından bir pull request açıyor. - react-bootstrap kaldırma işi için önceki bağlamı devralan ve mevcut oturumun ardından çalışacak bir “stacked session” oluşturuyor, plan üretiyor, onay istiyor ve planı yürütüyor.
- Bu yeni çalışmayı, ilk pull request’in üzerine oturan bir stacked pull request olarak açıyor.
Sonuçta yalnızca oturumlar değil, onların ürettiği değişiklikler de birbirini takip eden bir zincire dönüşüyor. Yazıda paylaşılan Copilot app görünümünde bu yapının katmanlı hali özetleniyor: en üstte depo, altında “Frontend modernization” isimli ilk oturum, onun altında iptal edilen ilk PR denemesi (kırmızı ikonla), aynı seviyede dev dalına açılan çalışan PR ve onun altında react-bootstrap değişikliklerini içeren taslak PR.
Neden önemli?
Yığınlı akışın pratik faydası, uzun süredir dokunulmamış bir kod tabanında bile değişikliklerin küçük, sıralı ve incelenebilir parçalar halinde ilerlemesi. Yazının vurguladığı deneyim, birbirine bağlı ama ayrı tutulması gereken işlerin tek bir dev PR’a sıkıştırılmadan aynı bağlam içinde yürütülebilmesi. Bu da özellikle bağımlılıkların birbirini etkilediği modernizasyon çalışmalarında hem incelemeyi kolaylaştırıyor hem de bir adımda hata çıktığında geri dönüşü hafifletiyor.
Pull request stack’leri, GitHub üzerinde kod commit ettiğiniz her yerde kullanılabiliyor; stacked sessions özelliği ise GitHub Copilot uygulaması içinden erişilebilir durumda.
İlgili okumalar
- GitHub Copilot app: Ajanlarla Çalışmanın Yeni Düzeni
- GitHub Copilot ile Pull Request İnceleme ve Code Review
- GitHub Pull Requests Dashboard: Herkes İçin Açılan Yeni Deneyim
- Claude Opus 4.8 GitHub Copilot’ta: Özellikler ve Geçiş
Kaynaklar ve İleri Okuma
- Stacked sessions and pull requests in the GitHub Copilot app – GitHub Blog
- Pull request stacks belgeleri
- GitHub Copilot app özellik sayfası
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder