GitHub'ı Slack ile Entegre Etme (Gürültüye Boğulmadan)
GitHub'ı Slack'e doğru biçimde bağlayın – resmi entegrasyonu kurun, bildirimleri etiket ve dala göre filtreleyin ve kanalları kullanışlı tutun.
By Ellis Keane · 2026-03-19
Az önce bir deploy başarısız oldu. Takımınızın koordine ettiği Slack kanalı sessiz – GitHub Actions uyarısını kimse görmedi çünkü uyarı, haftalar önce herkesin susturduğu #github-notifications kanalına gönderilmişti.
GitHub'ı Slack ile nasıl entegre edeceğinizi arıyorsanız, bu senaryonun muhtemelen sebebi budur. Bağlantı kurulumu birkaç dakika sürer (bizimkini bir toplantı arasında kurmuştum; geriye bakınca biraz iyimsermiş). Bunu gerçekten kullanışlı hale getirmek biraz daha uzun sürer ve bu eğitim tam da bunu ele alır.
Resmi GitHub-Slack entegrasyonunun yapabildiği (ve yapamadığı) şeyler
GitHub'ın resmi Slack uygulaması, PR'lar, sorunlar, deployment'lar ve commit'ler hakkındaki bildirimleri Slack kanallarına gönderir. Kanalları belirli repo'lara abone edebilir, etkinlik türüne göre filtreleyebilir ve bazı işlemleri doğrudan Slack'ten gerçekleştirebilirsiniz – sorun kapatma, yeni sorun açma gibi.
Yapamadığı şey bağlamı anlamaktır. README'deki bir yazım düzeltmesi, production hotfix ile aynı muameleyi görür. Bot tarafından açılmış bir bağımlılık güncellemesi, kritik bir güvenlik yamasının yanı başında yer alır. Bu entegrasyon bir boru hattıdır, filtre değil – boru hatları yalnızca içlerinden geçeni kontrol edebildiğinizde işe yarar.
"Bu entegrasyon bir boru hattıdır, filtre değil – boru hatları yalnızca içlerinden geçeni kontrol edebildiğinizde işe yarar." attribution: Chris Calo
(Çoğu takım bunu yaklaşık bir hafta içinde fark eder; #engineering kanalı kimsenin görmek istemediği commit'ler için bir borsa tekerine dönmeye başladığında.)
Slack için GitHub uygulamasını kurma
Üç adım ve hazırsınız:
- GitHub uygulamasını Slack'e yükleyin. Slack çalışma alanınızın uygulama dizinine gidin ve "GitHub" aratın. Çalışma alanı yönetici izinlerine ihtiyacınız olacak ya da bu izinlere sahip olup size borçlu olan birine.
- Kimlik doğrulayın. Herhangi bir kanalda
/github signin yazın. Bu, GitHub hesabınızı bağlar; Slack böylece daha zengin bildirimler gösterebilir ve sizi konuşmadan çıkmadan sorunlarla etkileşime geçirebilir.
- Bir kanalı repo'ya abone edin. Bildirimlerin görünmesini istediğiniz kanalda:
``` /github subscribe owner/repo-name ``` Varsayılan olarak issues, pulls, commits, releases ve deployments etkinliklerine abone olursunuz – beş etkinlik türü, çoğu kanalın ihtiyacından fazla.
- Hemen kırpın. Kanala hizmet etmeyen etkinliklerin aboneliğini iptal edin:
``` /github unsubscribe owner/repo-name commits ``` Çoğu mühendislik takımı için tutmaya değer olanlar pulls ve deployments'tır. issues, takımınızın GitHub'da mı yoksa Linear gibi ayrı bir takip aracında mı triyaj yaptığına bağlıdır. commits neredeyse her zaman gürültüdür – kod değişikliklerini görmek istiyorsanız PR'a bakın.
Tam komut referansı entegrasyon repo belgelerinde yer almaktadır.
Önce abone olun, ardından hemen kanalın amacına hizmet etmeyen etkinlik türlerinin aboneliğini iptal edin. Varsayılan "her şey" aboneliği, çoğu takımın kanalı tamamen susturmasının nedenidir.
GitHub'ı Slack ile gerçekten işe yarar bildirimler üretecek şekilde entegre etme
Çoğu eğitim burada durur ve çoğu entegrasyon sessizce işe yaramaz hale gelir. Abone ol/aboneliği iptal et sistemi kabadır – ya tüm PR'lar ya da hiç, ya tüm sorunlar ya da hiç. Kırk katkıcılı bir monorepo'nuz varsa "tüm PR'lar" bir sel olur.
Etiket tabanlı filtreleme geçici çözümdür ve gereğinden az kullanılır. Bildirimleri etikete göre filtreleyebilirsiniz:
``` /github subscribe owner/repo-name +label:"needs-review" ```
Artık kanal yalnızca needs-review etiketli PR veya sorunları görür. Etiketleri tutarlı biçimde kullanan takımlar için (bu gerçek bir kararlılık gerektirir, önemsiz bir şey değil) bu entegrasyonu gürültülüden faydalıya dönüştürür. Dikkat gerektiren PR'lar Slack'te görünür. Geri kalanı olduğu yerde, GitHub'da kalır.
İş akışı çalıştırması filtrelemesi, CI bildirimlerini dala göre daraltmanıza olanak tanır:
``` /github subscribe owner/repo-name workflows +branch:main ```
Bu, yalnızca main üzerinde tetiklenen iş akışı çalıştırmalarını göreceğiniz anlamına gelir – her feature branch CI çalıştırması değil. Takımınız deployment'lar için GitHub Actions kullanıyorsa, geliştirme dallarından gelen sürekli yeşil tik akışı olmadan production'a ilişkin uyarıları bu şekilde alırsınız.
Kanal mimarisi önemlidir. Her şey için tek bir #github kanalı susturmak için bir reçetedir. Bölmeyi düşünün:
| Kanal | Abonelikler | |-------|-------------| | #deploys | Yalnızca deployments | | #pr-reviews | pulls +label:"needs-review" | | #incidents | issues +label:"P0" |
Üç odaklanmış kanal, gürültülü birinden iyidir. Her birinin net bir amacı vardır ve takım üyeleri kendi rollerine uygun olanlara katılabilir. (Bunun bariz göründüğünü biliyorum ama tek bir #dev kanalının Slack bot'larını, GitHub bildirimlerini, deployment uyarılarını ve genel sohbeti yönettiği takımlar gördüm. Tam bir kaos.)
Yapılandırmaya değer üç iş akışı
Eski PR'lar için zamanlanmış hatırlatıcılar. GitHub'ın zamanlanmış hatırlatıcıları, inceleme bekleyen PR'lar için Slack'e dürtmeler gönderir. Bunu bir Slack komutuyla değil, GitHub'ın web arayüzünden (Ayarlar, ardından Zamanlanmış Hatırlatıcılar) yapılandırırsınız. Kimsenin fark etmediği için arka planda sessizce eskiyen PR'ları yakalar.
Deploy önizleme bağlantıları. Bir PR bir deployment önizlemesini tetiklediğinde (Vercel, Netlify veya benzer bir araç) durum Slack bildiriminde görünür. Tasarımcınız GitHub'ı açmadan önizleme URL'sine tıklayabilir – her inceleme başına bir bağlam değiştirme daha az.
İş parçacığı tabanlı konuşmalar. Bir PR bildirimine yapılan yorumlar Slack iş parçacığında kalır. "Güzel görünüyor, 47. satırda küçük bir not" yorumunuz bağlamın geri kalanının yaşadığı yerde gerçekleşir. Yorum GitHub'a geri senkronize olmaz (yalnızca Slack'te kalır); bu hem bir sınırlama hem de tartışmalı biçimde bir özellik.
Yerel entegrasyon tavan vurunca
Resmi entegrasyon çok şeyi kapsar ancak üstesinden gelemediği bazı örüntüler vardır:
Repo'lar arası görünürlük. Projeniz üç repo'ya yayılıyorsa üç ayrı aboneliğe ve üç ayrı filtre yapılandırmasına ihtiyacınız vardır. "Repo'lar genelinde Project X ile ilgili her şeyi göster" diye bir şey yoktur. Paralel yapılandırmaları korur ve tutarlı kalmalarını umarsınız.
GitHub'ı sorun takip aracınıza bağlama. Takımınız görevler için gerçeğin kaynağı olarak Linear kullanıyorsa GitHub-Slack entegrasyonu bu ilişkiyi bilmez. Bir PR bir Linear sorununu kapatabileceği halde Slack bunu bilmez – bildirim, bunun hangi görev için olduğu veya kimin beklediği hakkında bağlam içermeksizin "PR birleştirildi" der.
Ölçekte etiket disiplini. Etiket tabanlı filtreleme işe yarar ancak tutarlılık gerektirir – birinin etiket eklemesi gerekir ve bir PR etiketsiz gönderildiği anda filtre bozulur. Bakım yükü takımla birlikte büyür. Bir noktada filtreleri doğru tutmak için harcadığınız zaman, filtrelerden tasarruf ettiğinizden fazla olur.
(Bu, takımların Zapier'a veya özel bir bot'a uzandığı noktadır; bu da webhook kimlik doğrulaması bozulana, hız sınırı devreye girene veya biri ayrılıp kimse nasıl bağlandığını hatırlamayana kadar işe yarar.)
Sürdürülebilir hale getirme
GitHub-Slack entegrasyonu, ya görünmez (iyi yapılandırıldığı için) ya da aktif biçimde nefret edilen (yapılandırılmadığı için) araçlardan biridir. Fark kurulumda:
- Yalnızca kanalın amacına hizmet eden etkinlik türlerine abone olun
- Gürültüyü Slack'e ulaşmadan kesmek için etiket ve dal filtrelerini kullanın
- Bildirimleri tek bir genel kanal yerine odaklanmış kanallara dağıtın
- GitHub'ın web arayüzünden eski PR'lar için zamanlanmış hatırlatıcılar ayarlayın
- Yerel entegrasyonun sınırları olduğunu kabul edin – repo'lar arası bağlam veya sorun takip aracı bağlantıları önem kazandığında, bu katman için tasarlanmış araçlara bakın
GitHub'ı Slack ile entegre etmeniz gerekiyorsa yerel uygulama doğru başlangıç noktasıdır. Yukarıdaki filtreleme ve kanal mimarisi ipuçları onu ilk haftanın ötesinde kullanışlı tutacaktır. Bir bildirim boru hattının yapabileceklerini aştıysanız – eksik parça bir PR, ait olduğu Linear bileti ve yaklaşımın tartışıldığı Slack iş parçacığı arasındaki ilişkiyse – Sugarbug'ı tam da bunu çözmek için inşa ediyoruz.
GitHub, Linear, Slack ve Figma'yı tek bir bilgi grafiğine bağlayın – böylece her PR ait olduğu konuşmaya ve bilete bağlansın.
Q: GitHub'ı Slack ile nasıl entegre ederim? A: GitHub uygulamasını Slack'in uygulama dizininden yükleyin, /github signin ile kimlik doğrulayın, ardından /github subscribe owner/repo-name ile kanalları repo'lara abone edin. Etkinlik türlerini hemen kırpın – varsayılanlar her şeyi kapsar, bu neredeyse her zaman çok gürültülüdür.
Q: Sugarbug, GitHub-Slack entegrasyonunun yerini alabilir mi? A: Sugarbug, onu değiştirmek yerine yanında çalışır. Yerel entegrasyon bildirimleri işler; Sugarbug, GitHub PR'larını ilgili Linear sorunlarına, Slack tartışmalarına ve Figma tasarımlarına bağlayan bir bilgi grafiği oluşturur – böylece bir değişikliğin tam bağlamını görürsünüz, yalnızca bir PR'ın birleştirildiğini değil.
Q: Slack'teki GitHub bildirimlerini etikete göre nasıl filtrelerim? A: Abone olurken etiket filtresini kullanın: /github subscribe owner/repo-name +label:"needs-review". Yalnızca bu etikete sahip öğeler kanala gönderilir. Birden fazla etiket filtresini birleştirebilir ve bunları etkinlik türü abonelikleriyle karıştırabilirsiniz.
Q: Sugarbug, GitHub etkinliğini Slack ve Linear genelinde otomatik olarak takip eder mi? A: Evet. Sugarbug, GitHub, Slack ve Linear'a API aracılığıyla bağlanır ve aralarındaki etkinliği ilişkilendirir – bir GitHub PR'ı bir Slack konuşmasına atıfta bulunduğunda veya bir Linear biletini kapattığında bu bağlantılar, manuel etiketleme veya etiket disiplini olmadan bilgi grafiğinde izlenir.