GitHub’da yüzlerce açık pull request bulunan bir depoya girdiğinizde asıl sorun çoğu zaman kod değil, doğru işi bulmaktır. 10 Eylül 2026’da genel kullanıma açık ön izleme olarak duyurulan yeni depo düzeyindeki Pull requests sayfası; gelişmiş filtreleme, daha sıkı bir görünüm ve durum bilgisini listeye taşıyor. Değişiklik küçük bir arayüz yenilemesi gibi görünebilir, fakat iyi kullanıldığında inceleme kuyruğunu “kim önce bağırdı?” sırasından çıkarıp ölçülebilir bir iş akışına dönüştürebilir.

GitHub’ın duyurusuna göre ön izleme tüm GitHub kullanıcılarına açık. Yeni sayfa AND ve OR işleçleriyle iç içe aramaları destekliyor; daraltılabilir kenar çubuğu, kompakt görünüm, durum kontrolü sayıları, yığın göstergesi ve okunmamış güncelleme işaretleri sunuyor. Ancak ön izleme hâlâ eksik: kilometre taşları gösterilmiyor, toplu güncelleme yok, etiketlerdeki emojiler her zaman görünmüyor ve özel görünüm kaydetme desteklenmiyor.

Yeni sayfanın gerçek faydası nerede?

Bir pull request listesi yalnız kayıt ekranı değildir; ekibin teslimat darboğazını gösteren panodur. “Bana atanmış olanlar”, “inceleme bekleyenler” ve “kontrolleri geçmeyenler” aynı uzun listede kaybolduğunda ekip üyeleri kolay görünen işlere yönelir. Yeni içerik yardımı ve bileşik arama, soruyu daha açık kurmayı kolaylaştırıyor: örneğin hem belirli etiketi taşıyan hem de testleri başarısız olan işleri, başka bir öncelik kümesiyle birlikte göstermek mümkün.

Buradaki kritik ayrım şudur: gelişmiş filtre, doğru süreç anlamına gelmez. Filtre yalnız depodaki etiket, inceleme ve durum verisi kadar güvenilirdir. Kimsenin sahiplenmediği veya yanlış etiketlenmiş bir istek, en iyi sorguda bile görünmez olabilir. Bu yüzden yeni arayüzü açmadan önce ekibin “hazır”, “engelli” ve “acil” tanımlarını netleştirmesi gerekir.

10 dakikalık kabul testi

1. Aynı işi eski ve yeni görünümde bulun

Ön izlemeyi açmadan önce üç gerçek örnek seçin: size atanmış bir inceleme, kontrolleri başarısız bir pull request ve son 24 saatte güncellenmiş bir istek. Her birini klasik sayfada bulma süresini not edin. Ardından Preview rozetinden yeni sayfayı açıp aynı üç görevi tekrarlayın. Amaç “yeni daha güzel” demek değil; arama süresi ve yanlış seçim sayısını karşılaştırmaktır.

2. Bileşik filtreyi sınayın

İçerik yardımını kullanarak iki koşullu bir arama kurun. Sonra aynı sorguya üçüncü bir koşul ve alternatif bir grup ekleyin. AND, iki koşulun birlikte sağlanmasını; OR ise iki kümeden birinin eşleşmesini ister. İç içe sorgularda parantez mantığını ekipçe aynı örnek üzerinde doğrulayın. Beklediğiniz on kayıt yerine yüz kayıt geliyorsa sorun yeni sayfada değil, sorgu mantığında olabilir.

3. Liste bağlamını kontrol edin

Kompakt görünümde daha fazla satır görmek faydalı, ancak karar için gerekli bilgiyi saklamamalı. Üç pull request’te durum kontrolü sayısını, okunmamış güncelleme işaretini ve varsa yığın göstergesini ayrıntı sayfasıyla karşılaştırın. Bir göstergeyi “merge edilebilir” diye yorumlamadan önce neyi temsil ettiğini doğrulayın. Özellikle yeşil test işareti, insan incelemesinin tamamlandığı anlamına gelmez.

4. Bilinen eksiklerle süreç çakışıyor mu?

Ekibiniz kilometre taşlarını veya toplu etiket değiştirmeyi günlük kullanıyorsa ön izlemeye tamamen geçmek için acele etmeyin. Duyuruda bu alanların henüz desteklenmediği açıkça belirtiliyor. Özel görünümlerin kaydedilememesi de paylaşılan kuyrukların bağlantı veya ekip dokümanı üzerinden tarif edilmesini gerektirebilir. Ön izleme rozetinden klasik deneyime geri dönülebiliyor; bu yüzden pilotu tek bir depoda başlatmak daha güvenli.

Türkiye’deki küçük ekip için sade kuyruk modeli

Dört sütunlu bir haftalık kontrol tablosu yeterli olabilir: “inceleme bekliyor”, “test başarısız”, “yanıt bekliyor” ve “birleştirmeye hazır”. Her sütun için bir GitHub sorgusu yazın ve sorumlu kişiyi belirleyin. Pazartesi günü açık istek sayısını, cuma günü kapanan ve yeniden açılan istekleri karşılaştırın. Uzaktan çalışan Türkiye ekiplerinde saat farkı varsa “son güncellenme” ile “ilk açılma” süresini karıştırmayın; biri iletişim gecikmesini, diğeri toplam çevrim süresini gösterir.

Yeni görünüm, büyük ve tek parça değişiklikleri otomatik olarak küçültmez. İncelemesi zor yığınları azaltmak için pull request kapsamını ayrıca sınırlayın. Her işin bir sahibi ve görünür bir sonraki adımı olmalı. İnceleme kuyruğunu düzenlerken merge öncesi sır taraması kuralını da ayrı bir güvenlik kontrolü olarak değerlendirin. Güvenlik açısından ise depoya yanlışlıkla anahtar girmişse yalnız filtrelemek yeterli değildir; anahtarı iptal edip kullanım kayıtlarını incelemek gerekir.

Yayın öncesi kontrol listesi

  • Ön izlemeyi önce tek depoda ve küçük bir inceleme grubuyla açın.
  • Üç gerçek görevin eski ve yeni görünümde bulunma süresini ölçün.
  • AND, OR ve iç içe sorgu sonuçlarını elle sayın.
  • Durum kontrolü, okunmamış güncelleme ve yığın göstergesini ayrıntı sayfasıyla doğrulayın.
  • Kilometre taşı, toplu güncelleme ve kayıtlı görünüm eksiklerinin süreci bozup bozmadığını yazın.
  • Beklenmeyen davranışta Preview rozetinden klasik görünüme dönün.

Sonuç: filtreyi değil, kararı test edin

GitHub’ın yenilenen Pull requests sayfası daha yoğun depolarda arama ve önceliklendirmeyi hızlandırabilecek araçlar sunuyor. Fakat public preview etiketi, eksiklerin ve davranış değişikliklerinin sürebileceğini hatırlatıyor. En doğru geçiş, ekibin gerçek kuyruğundan küçük bir örnekle ölçüm yapmak; doğru kayıtları daha hızlı bulduğunuzu ve kritik bağlamı kaybetmediğinizi kanıtladıktan sonra kapsamı genişletmektir.

Kaynak: GitHub Changelog, “Refreshed repository pull requests page in public preview”, 10 Eylül 2026.