GitHub Bildirimlerinde Sıralama Geldi: Küçük Detay mı?
Biliyor musunuz, bazen bir ürüne yıllardır beklediğiniz özellik gelir ve “ya sonunda!” diye bağırırsınız. Bazen de o özellik o kadar bariz bir şeydir ki herkes “bunu neden daha önce yapmadılar ki?” diye sorar (buna dikkat edin). GitHub’ın bildirım sayfasına gelen yeni “Sort by” kontrolü bana kalırsa ikinci kategoriye giriyor. Peki ama, bu kadar yalın bir şeyi neden 1400 küsur kelimeyle anlatıyorum? Çünkü işin altında göründüğünden daha fazlası var.
📋 İçindekiler
Doğrusu, Geçen ay bir müşterimde — orta ölçekli bir fintech firması — sprint retrospective yapıyorduk. Ekipten bir geliştirici “Ben GitHub bildirimlerimi hiç okumuyorum artık, 300 tane birikmiş, en eskisine ulaşmak için sayfa sayfa geri gitmem gerekiyor” dedi. Herkes güldü. Ama aslında ciddi bir verimlilik meselesi bu. İşte GitHub da nihayet bu basit ama can yakıcı soruna el attı.
Hmm, bunu nasıl anlatsamdı…
Ne Geldi, Ne Değişti?
İtiraf edeyim, GitHub’ın Notifications sayfasına yeni bir “Sort by” kontrolü eklendi. İki seçenek var:
- Newest to oldest — Zaten eskiden de böyleydi, yeniden eskiye sıralama
- Oldest to newest — İşte yeni gelen bu: eskiden yeniye sıralama
Kağıt üstünde bakınca “iki seçenekli bir dropdown” gibi dürüyor (en azından benim deneyimim böyle). Hepsi bu mu? Teknik olarak evet. Ama pratikte bu ufak ekleme, bildirım yönetiminin tamamını değiştiriyor — seçtiğiniz sıralama tüm görünümlerde (All, Unread, vb.) geçerli oluyor ve oturumlar arasında kalıcı. Bu kısmı önemli. Yanı bir kere “eskiden yeniye” diyorsunuz, tarayıcıyı kapatıp açsanız bile aynı şekilde devam ediyor.
Araya gireyim: Ha bir de şu var. Bildirimleriniz repository’ye göre gruplandığında, sıralama hem grupların kendi sırasını hem de her grubun içindeki öğelerin sırasını etkiliyor (bizzat test ettim). Sadece yüzeysel bir sıralama değil yanı, derine iniyor.
Neden Bu Kadar Geç Geldi?
Eh, Bu soruyu sormadan geçemiyorum. Ciddi ciddi, 2026 Nisan’ındayız ve GitHub’a bildirım sıralama özelliği yeni mi geliyor? Bir düşüneyim (ki bu çoğu kişinin gözünden kaçıyor). GitHub 2008’den beri var. 18 yıl. E-posta istemcileri 1990’lardan beri sıralama yapabiliyor. Hmm.
Ama şunu da söylemek lazım — büyük platformlarda “basit görünen” özellikler her zaman basit olmuyor. GitHub’ın bildirım sistemi düşündüğünüzden çok daha karmaşık bir altyapı üstünde dürüyor; milyonlarca kullanıcının bildirimlerini gerçek zamanlı takip etmek, gruplamak, filtrelemek (buna dikkat edin). Üstüne bir de sıralama tercihi ekleyip bunu session bazında persist etmek, backend tarafında ufak da olsa bir iş. Küçümsemiyorum.
Şimdi gelelim işin can alıcı noktasına.
Açık konuşayım, Yine de açık konuşayım. Şu özellik çok daha önce gelebilirdi. GitHub son birkaç yılda Copilot’a, AI özelliklerine o kadar yoğunlaştı ki — haklı olarak da yoğunlaştı, bunu da söyleyeyim — bu tür temel UX iyileştirmeleri hep geride kaldı (evet, doğru duydunuz). 2023’te tuttuğum bir notta “GitHub’ın notification sistemi son 5 yılda neredeyse hiç değişmedi” diye yazmışım. Şimdi değişmeye başlıyor. Geç de olsa.
Gerçek Hayatta Ne Fark Ediyor?
Backlog Temizliği Artık Gerçekten Mümkün
Eskiden ne yapıyorduk? Diyelim 500 tane birikmiş bildiriminiz var. En eski bildirime ulaşmak istiyorsunuz çünkü öncelik sırasına göre çalışmak istiyorsunuz. Son sayfaya git, oradan geriye doğru çalış… Ama her sayfada 25 bildirım varsa 20 sayfa ileri gideceksiniz, bir bildirime tıklayıp geri döndüğünüzde sayfa sıfırlanıyor mu kalmıyor mu — o da ayrı bir muamma. Şimdi, sınır bozucu.
Ve işler burada ilginçleşiyor.
Şimdi tek tıkla “Oldest to newest” seçiyorsunuz. Bitti. En eski bildirimleriniz en üstte. Sırayla gidiyorsunuz. Bu kadar.
Eh, Logosoft’ta çalıştığım bir kamu projesinde DevOps ekibi 4 farklı repo’yu takip ediyordu. Bildirimler öyle bir birikiyordu ki… Ekip lideri bir noktada “ben bildirimleri tamamen kapattım, Slack’ten takip ediyorum” demişti. Hani biraz trajikomik ama gerçek. O ekibe bu özelliği gösterdim geçen hafta. Adam “ciddi mısın, bu mu yoktu?” dedi. Tam da öyle. Daha fazla bilgi için GitHub Copilot for Eclipse Açık Kaynağa Dönüyor: Neden Önemli? yazımıza bakabilirsiniz.
Repository Gruplarında Derinlemesine Sıralama
Bu kısım bence en güzel tarafı. Bildirimlerinizi repo bazında grupladığınızda, sıralama sadece grupları değil, her grubun içindeki bildirimleri de etkiliyor — yanı hem “hangi repo’nun bildirimi daha eski” hem de “o repo içinde hangi bildirım daha eski” sorusunun cevabını aynı anda alıyorsunuz, fazladan bir tıklama gerekmeden.
Bunu biraz açayım.
Bunu bir örnekle anlatayım. Diyelim 3 repo’nuz var:
| Repository | En Eski Bildirım | Toplam Bildirım |
|---|---|---|
| frontend-app | 12 Mart 2026 | 47 |
| backend-api | 3 Nisan 2026 | 12 |
| infra-terraform | 8 Nisan 2026 | 5 |
“Oldest to newest” seçtiğinizde frontend-app grubu en üstte çıkıyor — çünkü en eski bildirım orada — ve o grubun içinde de 12 Mart’taki bildirım en üste geliyor. Mantıklı, tutarlı, öngörülebilir. Daha önce bunu yapmaya çalışıyordunuz, her gruba ayrı ayrı girip en alta scroll etmeniz gerekiyordu. Evet, o kadar saçmaydı. Bu konuyla ilgili github ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
Session Kalıcılığı Meselesi
Bakın, Dur bir saniye, bu kısım göz ardı edilmemeli. Sıralama tercihinin oturumlar arasında persist etmesi — yanı tarayıcıyı kapatıp açtığınızda bile aynı kalması — ufak. Önemli bir teknik detay. GitHub bunu muhtemelen kullanıcı profili bazında backend’de saklıyor, localStorage gibi bir client-side çözüm kullanmıyordur.
Bence, Neden önemli? Çünkü ben daha önce bazı web uygulamalarında “sıralama tercihi” özelliklerinin sadece o session’da geçerli olduğunu gördüm. Tarayıcı kapanıyor, her şey sıfırlanıyor (evet, doğru duydunuz). Sınır bozucu. GitHub bunu doğru yapmış; her seferinde “oldest to newest” tıklamak zorunda kalmıyorsunuz.
Küçük bir UX detayı: Sıralama tercihiniz bir kere kaydediliyor ve tüm görünümlerde (All, Unread, Saved vb.) geçerli oluyor. Her sekme için ayrı ayrı ayarlamanıza gerek yok.
Eksik Kalanlar ve Eleştirilerim
Güzel özellik, evet — Ama benim beklentimi tam karşıladı mı? Hayır (ben de ilk duyduğumda şaşırmıştım). Açık konuşayım, birkaç şey eksik kalmış.
Bilmem anlatabiliyor muyum, Birincisi: neden sadece tarih bazlı sıralama var? “Priority” bazlı sıralama nerede? Ben mesela bildirimleri “mention” olanlar üste, “team mention” olanlar ortaya, “subscribed” olanlar alta gibi bir mantıkla görmek isterdim. Bu yok. Hiç yok.
İkincisi: filtreleme hâlâ yetersiz. Sıralama güzel de, ben “sadece son 7 günün bildirimlerini göster” veya “sadece PR review isteklerini göster” gibi filtreler istiyorum. Bunlar hâlâ eksik. 2026’da bile GitHub’ın bildirım sayfası bir e-posta istemcisinin filtreleme kapasitesinin gerisinde kalıyor. Biraz düşündürücü. AG-UI ile Çoklu Ajan Arayüzü: Gerçek Zamanlı Demo yazımızda bu konuya da değinmiştik.
Üçüncüsü — ve bu biraz niş bir şikayet ama — API tarafında bu sıralama parametresi henüz destekleniyor mu bilmiyorum. GitHub API üzerinden bildirimlerini çeken ve kendi dashboard’ını yapan insanlar var, ben dahil: 2021’de bir ara kendime özel bir bildirım paneli yazmıştım. API’da sort parametresi yoksa bu iyileştirme sadece web arayüzüyle sınırlı kalıyor. Biraz yarım kalmış hissettiriyor o açıdan.
Bildirım Yönetimi İçin Pratik Öneriler
Küçük Takımlar İçin
5-10 kişilik bir ekipseniz, bildirım birikimi genelde çok sorun olmaz. Ama yine de haftada bir “bildirım temizliği” alışkanlığı edinmenizi tavsiye ederim (inanın bana). Peki, “Oldest to newest” sıralayın, en eskiden başlayarak sırayla geçin — bu sayede unutulmuş bir PR review isteğini ya da kapanmamış bir issue’yu kolayca yakalarsınız. Sız hiç denediniz mi? Küçük ama etkili bir alışkanlık. Bu konuyla ilgili github konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim.
Enterprise Seviyede
Doğrusu, Büyük organizasyonlarda durum farklı. 50+ repo, yüzlerce geliştirici, binlerce bildirım… Bu noktada GitHub’ın bildirım — ki bu tartışılır — sayfası tek başına zaten yetmiyor. Çoğu kurumsal müşterimde Slack veya Teams entegrasyonu, GitHub Actions ile özel bildirım workflow’ları, hatta üçüncü parti araçlar (Octobox, DevHub gibi) kullanılıyor. Ama en azından GitHub’ın kendi arayüzünde temel bir sıralama olması, “quick check” senaryolarında işe yarıyor. Fena değil. Bu konuyla ilgili github ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
2024’te bir bankacılık müşterimizde GitHub Enterprise’ı kurmuştuk. Onların en büyük şikayetlerinden biri bildirım yönetimiydi. O zaman “GitHub bu konuda zayıf, Slack entegrasyonuyla aşın” demiştik. Şimdi en azından bir adım atılmış oluyor — ama daha çok yol var önde.
Açık Kaynak Proje Maintainer’ları İçin
Eğer popüler bir açık kaynak projeniz varsa, bu özellik hayat kurtarıcı olabilir. Neden? Çünkü issue ve PR bildirimleri durdurulamaz bir şekilde akıyor. Maalesef. Peki, “Oldest to newest” ile en eski bildirimlere öncelik vererek, topluluktan gelen eski issue’ları veya PR’ları atlamadan sırayla işleyebilirsiniz. Bana kalırsa bu özelliğin asıl hedef kitlesi maintainer’lar zaten.
GitHub’ın UX Evrimine Genel Bakış
Bir adım geri çekilip bakarsak, GitHub son 2 yılda UX tarafında ciddi hamleler yapıyor. İssues araması anlam bazlı çalışmaya başladı — ki bu konuyu daha önce GitHub Issues Araması Değişti: Artık Anlamla Buluyor yazısında ele almıştım. Diff satırları büyük PR’larda hızlandırıldı, güvenlik sekmesi yeniden tasarlandı.
Gel gelelim, bildirım sayfası bu evrimin en geride kalan parçasıydı. Şimdi sıralama geldi, güzel. Ama hâlâ çok temel. Filtreleme, etiketleme, toplu işlem (bulk actions), özel görünümler… Bunlar olmadan GitHub’ın bildirım sistemi “idare eder” seviyesinde kalıyor. E sonra? Heyecan verici değil. Ama doğru yönde.
Ne yalan söyleyeyim, Şunu da ekleyeyim: GitHub’ın bu tür küçük iyileştirmeleri changelog’da duyurması. Community discussion açması güzel bir yaklaşım. En azından dinliyorlar, hissediyorsunuz. Feedback vermeye devam edelim, belki bir sonraki adımda “priority sort” veya “custom filters” gelir. Bu arada GitHub’ın son dönemdeki dayanıklılık çalışmalarına da göz atmanızı öneririm: GitHub’un Mart 2026 Dersi: Dayanıklılık Kağıt Üstünde Değil yazım bu konuda detaylı bir analiz içeriyor.
Sıkça Sorulan Sorular
GitHub’da bildirım sıralaması nasıl değiştirilir?
Şöyle söyleyeyim, GitHub Notifications sayfasına gidin, sayfanın üst kısmında yeni eklenen “Sort by” dropdown menüsünü göreceksiniz. “Newest to oldest” veya (belki yanılıyorum ama) “Oldest to newest” seçeneklerinden birini tıklayın. Tercihiniz otomatik olarak kaydedilir ve bir sonraki ziyaretinizde de geçerli olur.
Sıralama tercihi her seferinde sıfırlanıyor mu?
Hayır, sıralama tercihiniz oturumlar arasında kalıcı. Tarayıcıyı kapatıp açsanız, farklı bir cihazdan giriş yapsanız bile seçtiğiniz sıralama korunuyor. GitHub bunu hesap bazında saklıyor.
Repository grupları içinde de sıralama çalışıyor mu?
Evet. Bildirimler repository’ye göre gruplandığında, sıralama hem grupların kendi sırasını hem de her grubun içindeki bildirimlerin sırasını etkiliyor. Yanı “oldest to newest” seçtiyseniz, en eski bildirime sahip repo grubu en üstte çıkar ve o grubun içinde de en eski bildirım en üsttedir.
GitHub Notifications API’sinde de bu sıralama desteği var mı?
Şu an için resmî bir açıklama yapılmadı. GitHub Notifications REST API’si varsayılan olarak “last_read_at” veya “updated_at” bazlı sıralama sunuyor ama web arayüzündeki bu yeni “sort by” parametresinin API’ye yansıyıp yansımadığı net değil. API dokümantasyonunu takip etmenizi öneririm.
Bu özellik GitHub Enterprise Server’da da mevcut mu?
Şu an sadece GitHub.com’da (GitHub Enterprise Cloud dahil) kullanılabilir durumda. GitHub Enterprise Server’a gelip gelmeyeceği henüz duyurulmadı. Genellikle bu tür UI iyileştirmeleri birkaç GHES sürümü sonra aktarılıyor.
Kaynaklar ve İleri Okuma
GitHub Changelog: New Sort by control added to Notifications
GitHub Docs: Viewing and triaging notifications
GitHub REST API: Notifications endpoint
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
4 comments