GitHub Bildirim Saklama Süresi Kısalıyor: Ne Yapmalı?
Garip gelecek ama, Dün sabah GitHub hesabımı açtığımda, gelen kutumda 340 küsur okunmamış bildirim vardı. Yüzlercesi aylardır arşivlenmiş repoların watch bildirimleri, bir kısmı da üç-dört ay öncesinden kalmış eski issue yorumlarıydı (ben de ilk duyduğumda şaşırmıştım). Hani şöyle bir baktım, “bunların yarısını niye saklıyorum ki?” dedim. Tam da bu düşünceyle GitHub’ın yeni duyurduğu iki değişiklik bana baya yerinde geldi, en azından benim için.
Hani, GitHub, bildirim saklama süresini ve arşivlenmiş repo watch’larını etkileyen iki önemli güncelleme yayınladı. Kısaca: web bildirimleri artık 5 ay değil 3 ay saklanacak, 6 aydan uzun süredir arşivlenmiş repolardaki watch’lar işe kaldırılacak. Kulağa basit geliyor ama… aslında altta yatan mesele biraz daha derin. Gelin birlikte bakalım.
Web Bildirimleri: 5 Aydan 3 Aya İndi, E Peki?
İlk değişiklik şu: GitHub’ın web arayüzündeki bildirimler artık 5 ay yerine 3 ay tutulacak. 3 ay sonra gelen kutudan silinecekler. E-posta bildirimleri bu değişiklikten etkilenmiyor; orası aynı kalıyor (evet, doğru duydunuz)
Şimdi bazılarınız “3 ay mı? Az değil mi?” diye düşünebilir. Ben de ilk anda öyle düşündüm açıkçası. Ama sonra bir oturup kendi alışkanlıklarımı yokladım. Son 5 ayın bildirimlerine ne zaman geri döndüm? Hmm… Bir düşüneyim. Hiç. Yanı gerçekten hiç. En fazla 2 haftalık bildirimlere bakıyorum, ondan ötesi zaten kafamda çoktan uçup gidiyor.
İnanın, Logosoft’ta DevOps danışmanlığı yaptığım bir finans kurumu var — oradaki ekip GitHub Enterprise kullanıyor ve yaklaşık 180 repo yönetiyorlar. Geçen ay bir toplantıda “bildirim kirliliği” konusu açıldı. Ekip lideri şöyle dedi: “Herkes bildirimleri kapatmış, kimse bakmıyor artık.” İşte tam da bu sorunun kökeninde, yüzlerce eski bildirimin gelen kutusunu gereksiz yere işgal etmesi yatıyor.
Bu Değişiklik Kimleri Etkiler?
Bunu yaşayan biri olarak söyleyeyim, Açık konuşayım: eğer bildirimleri zaten e-posta üzerinden takip ediyorsanız, bu değişiklik sizi pek etkilemez. Sıfır gibi düşünün. Ama web arayüzünden takip edenler için — özellikle açık kaynak projelere katkı yapanlar ve birden fazla organizasyonda çalışanlar için — biraz dikkat etmek lazım. 3 aydan eski bir issue’ya dönüp “aa burada bana yorum gelmişti” deme şansınız artık yok.
Dürüst olmak gerekirse, Pratik öneri şu: eğer önemli bir bildirimi kaybetmek istemiyorsanız, GitHub’ın “Save” özelliğini kullanın. Ya da daha iyisi, kilit bildirimleri bir proje yönetim aracına (Azure Boards, Jira, Linear fark etmez) aktarın. Ben kendi workflow’umda GitHub Actions ile önemli bildirimleri otomatik olarak bir Teams kanalına yönlendiriyorum; baya iş görüyor.
Arşivlenmiş Repo Watch’ları Temizleniyor
İkinci değişiklik belki daha ilginç: 6 aydan uzun süredir arşivlenmiş olan repolarda, eğer o repoya doğrudan erişiminiz yoksa (yanı collaborator, org üyesi ya da takım üyesi değilseniz), watch’ınız otomatik olarak kaldırılacak.
Mantığı şu: arşivlenmiş repolar zaten read-only. Yeni commit, issue, PR falan gelmiyor. Yanı watch’ınız hiçbir bildirim üretmiyor, boşuna orada dürüyor. GitHub da diyor ki “biz bu gereksiz veriyi temizliyoruz.”
Bak bir de şunu söyleyeyim — bu değişiklik repo sahiplerini de etkiliyor. Arşivlenmiş repolarınızın watcher sayısı düşecek. Yanı eskiden “vay 500 kişi izliyor bu repoyu” dediğiniz projede, bir baktınız sayı 150’ye düşmüş. Panik yapmayın. Gerçek takipçi sayınız zaten o 150’ydı; diğer 350 kişi muhtemelen yıllar önce watch’lamış ve unutmuştu.
Peki Ya Repo Tekrar Aktif Olursa?
İşin garibi, Güzel soru. Eğer arşivlenmiş bir repo daha sonra unarchive edilirse, tek tıklamayla tekrar watch’layabilirsiniz. Yanı kalıcı bir kayıp yok. Ama — ve bu önemli bir “ama” — bunu yapmanız gerektiğini hatırlamanız lazım. Kimse size “hey, şu repo tekrar aktif öldü, tekrar izlemek ister mısın?” diye ekstra bir bildirim göndermeyecek.
Şimdi gelelim işin can alıcı noktasına.
2023’te bir müşterimde yaşadığımız bir olay var: eskiden kullandıkları açık kaynak kütüphane arşivlenmişti, sonra maintainer geri döndü. Projeyi canlandırdı. Ama ekip bunu 3 ay sonra fark etti çünkü kimse artık o repoyu izlemiyordu. Yeni değişiklikle bu tarz durumlar biraz daha görünmez hâle gelebilir. Daha fazla bilgi için github konusundaki yazımız yazımıza bakabilirsiniz.
Türkiye’deki Ekipler İçin Pratik Etkileri
Şahsen, Türkiye’deki yazılım ekiplerinin GitHub kullanım alışkanlıkları, özellikle kurumsal tarafta, biraz farklı oluyor. Benim gözlemlerime göre — ki son 5 yılda onlarca şirketle çalıştım — Türkiye’de GitHub bildirimleri çoğu zaman göz ardı ediliyor (yanlış duymadınız). Çoğu ekip Slack veya Teams entegrasyonuyla ilerliyor, doğrudan GitHub’ın bildirim sistemine pek güvenmiyor.
Burada, garip gelecek ama, Ama işte startup’larda tablo farklılaşıyor. Küçük ekiplerde (3-5 kişi) herkes her şeyi izliyor; bildirimler daha kişisel ve daha değerli oluyor. Bu tarz ekipler için 3 aylık saklama süresi yeterli bile gelebilir. Zaten her şey anlık takip ediliyor (en azından benim deneyimim böyle) Azure MCP Server .mcpb Paketi: Kurulum Artık Çocuk Oyuncağı yazımızda bu konuya da değinmiştik.
Evet, doğru duydunuz.
Bak şimdi, Kurumsal tarafta işe asıl mesele compliance oluyor. Bazı sektörlerde (finans, sağlık) “kim ne zaman hangi değişikliği gördü” sorusunun cevabı önemli olabiliyor. GitHub web bildirimleri resmî bir audit log değil tabi ama — dur bir saniye, aslında şunu net söylemem lazım — eğer audit amaçlı bildirim takibi yapıyorsanız zaten yanlış yoldasınız (inanın bana). GitHub Audit Log API’si var; önü kullanın. Bu konuyla ilgili github konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim.
Bildirim Yönetimi İçin Önerilerim
Bu değişiklikleri fırsat bilip bildirim stratejinizi gözden geçirmenizi öneririm (kendi tecrübem). İşte benim yıllardır uyguladığım ve danışmanlık verdiğim ekiplere de önerdiğim yaklaşım: (şaşırtıcı ama gerçek)
- Watch sayınızı azaltın: Gerçekten takip etmeniz gereken repoları belirleyin. Ben şu an sadece 12 repoyu aktif olarak watch’lıyorum; geri kalanını “Participating and @mentions” moduna aldım.
- Custom routing kurun: GitHub notification settings’den hangi tür bildirimlerin e-posta ile geleceğini, hangilerinin sadece web’de görüneceğini ayarlayın. CI/CD failure’ları e-posta’ya, genel tartışmalar sadece web’e gitsin mesela.
- Haftalık temizlik alışkanlığı edinin: Her cuma 10 dakika ayırıp bildirimleri temizleyin. Ben bunu 2021’den beri yapıyorum; hayat kurtarıyor diyebilirim. (bence en önemlisi)
- Otomasyon kurun: GitHub Actions veya Azure Logic Apps ile kilit bildirimleri Teams/Slack’e yönlendirin. Geri kalanını bırakın GitHub’da kalsın — ve 3 ay sonra kendiliğinden gitsin. — bunu es geçmeyin
Watch Stratejisi Karşılaştırması
| Senaryo | Önerilen Watch Modu | Bildirim Kanalı |
|---|---|---|
| Kendi aktif projeniz | All Activity | E-posta + Web |
| Ekip arkadaşının reposu | Participating & @mentions | Sadece Web |
| Takip ettiğiniz açık kaynak proje | Releases Only | E-posta |
| Arşivlenmiş repo | Unwatch | Yok — gerek yok |
| Bağımlılık olarak kullandığınız kütüphane | Custom (Security alerts) | E-posta + Otomasyon |
Bildirim yönetimi, kod yazmak kadar önemli bir mühendislik pratiğidir. Gürültüyü azaltamazsanız, gerçekten önemli olan sinyalleri de kaçırırsınız.
GitHub’ın Veri Temizliği Stratejisi:Büyük Resim
Bu değişikliği tek başına değerlendirmeyin derim.Burada başka şeyler de dönüyor.GitHub son birkaç yılda ciddi bir “veri hijyeni” işi yapıyor.Token formatı değişiklikleri, eski API’lerin sunset edilmesi,inactive hesapların uyarılması… Hepsi aynı çizginin parçası.Daha önce GitHub App Token Formatı Değişiyor:Hazırlık Rehberiwritımda token tarafındaki değişikliklere değinmiştim.Bu bildiri güncellemesi de aynı hatta dürüyor aslında.
İtiraf edeyim, Açık konuşayım:bence GitHub bu temizliklerle hem depolama maliyetlerini aşağı çekiyor hem de GDPR ve benzeri regülasyonlara uyum sağlamaya çalışıyor.”Sizin adınıza sakladığımız eski veriyi azaltıyoruz” cümlesi aslında biraz da “gereksiz veri tutmanın hukukî riski var” demek.Yanlış anlamayın,bunu kötü diye söylemiyorum.Hatta doğru yönde atılmış bir adım.Ama GitHub bunu “sizin gelen kutunuzu temiz tutuyoruz” diye anlatıyor;gerçekte motivasyon biraz daha karışık yanı.
“
Hayal Kırıklığı mı? Pek Değil Ama…
Açık kaynak topluluğunda bu değişikliğe tepkiler karışık.Bazıları “sonunda” derken,bazıları da “ama ben 4 ay önceki bir bildirimi arıyordum” diye şikayet ediyor.Ben ortada bir yerdeyim.3 ay makul süre gibi dürüyor ama keşke kullanıcıya seçim hakkı verselerdi.Hani “sen 3 ay işte,ben6 ay istiyorum” gibi bir ayar olsa fena olmazdı.Belki ileride gelir,bilemiyorum. Axios npm Saldırısı: Azure Pipelines’ta Ne Yapmalı? yazımızda bu konuya da değinmiştik.
Arşivlenmiş repo watch’larının temizlenmesi konusunda işe sıfır şikayetim var.Zaten pek işe yaramıyordu.Benim hesabımda 20’den fazla arşivlenmiş repo watch’ı vardı;hepsini manuel temizlemem gerekiyordu, şimdi GitHub benim yerime yapacak.Güzel işte.
Ha bu arada,eğer GitHub Actions kullanıyorsanızve CI/CD pipeline’larınızın bildirimgilerini web üzerinden takip ediyorsanız,bu 3 aylık süre pipeline hatalarını geriye dönük incelemenizi zorlaştırabilir.Bu durumda Azure DevOps Server Nisan Yaması :Ne Geldi,Ne Yapmalı?writımdaki gibi ayrıbir loglama mekanizması kurmanızı öneriyorum. Ingress-NGINX Göçü: 5 Şaşırtıcı Davranış ve Çözümü yazımızda bu konuya da değinmiştik.
Neyapmalısınız? Kısa Aksiyon Listesi
Değişiklikler önümüzdeki birkaç ay içinde kademeli olarak uygulanacak.Su an yapmanız gerekenler :
- GitHub gelen kutunuza gidin,3 aydan eski önemlibildirmleri kaydedin veya not alın
- Watch listenizdeki arşivlenmiş repoları gözden geçirin-hangilerini gerçekten takip etmek istiyorsunuz ?
- E-posta bildirimiayarınızı kontrol edin-web bildirmleri kısalıyor ama e-posta aynı kalıyor
- Ekibinize bu değişikliği duyurun -özellikle açık kaynak katkı yapan geliştiricilere
- Otomasyon kurmayı düşünün:kritikbildirmleri kalıcıbir kanala yönlendirin
Sonuç olarakbu devbirdeğişiklik mi?Hayır.Amabildirm hijyenini ciddiye almanız için güzelbir bahane.Benim tavsiyem:bunu birofırsat olarak görünvebildrim stratejinizi baştan kurun.10 dakikalıkbir iş,ama uzun vadede saatler kazandırır.
Sıkça Sorulan Sorular
GitHub web bildirimleri 3 aya inince e-posta bildirimleri de etkileniyor mu?
Hayır, e-posta bildirimleri bu değişiklikten hiç etkilenmiyor. Yanı sadece GitHub web arayüzündeki (github.com/notifications) bildirimler 3 ay sonra otomatik siliniyor. E-posta kutunuzdaki bildirimler işe e-posta sağlayıcınızın kurallarına tabi — o taraf büyük ölçüde ayrı.
Arşivlenmiş repodaki watch’ım kaldırılırsa tekrar watch’layabilir mıyım?
Evet, repo ileride unarchive edilirse sayfasından tek tıklamayla geri watch’layabilirsiniz. Ama açıkçası, repo arşivli kaldığı sürece zaten bildirim üretmiyor — yanı o watch’ın pratikte bir anlamı da kalmıyor.
Repo sahibiysem arşivlenmiş repomdaki watch’ım da kaldırılıyor mu?
Hayır, sizi bu temizlik kapsamıyor. Repo sahipleri, organizasyon üyeleri, doğrudan collaborator’lar ve takım üyeleri muaf. Bence bu mantıklı bir ayrım — sadece dışarıdan watch’lamış kullanıcıların watch’ları kaldırılıyor.
Bu değişiklikler ne zaman yürürlüğe giriyor?
GitHub, değişikliklerin kademeli dağıtılacağını ve birkaç ay içinde tamamlanacağını söylüyor. Kesin tarih verilmedi, ama 2026’nın ikinci çeyreğinde çoğu hesapta aktif olması bekleniyor. Yanı biraz sabır gerekiyor.
3 aydan eski önemli bir bildirimi kaybetmemek için ne yapabilirim?
GitHub’ın “Save” özelliğiyle önemli bildirimleri işaretleyebilirsiniz — hani o küçük yer ımı ikonu (buna dikkat edin). Tecrübeme göre daha sağlam çözüm işe kritik bildirimleri GitHub Actions veya webhook’lar aracılığıyla Slack, Teams ya da bir veritabanına yönlendirmek. Biraz kurulum istiyor ama uzun vadede çok daha güvenli.
Kaynaklar ve İleri Okuma
Changes to notification retention and archived repository watches — GitHub Blog
Configuring notifications — GitHub Docs
Watching Repositories REST API — GitHub Docs
İçeriği paylaş:
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.







Yorum gönder