Home | Blog | Integration

Integrasi GitHub dengan Slack (Tanpa Kebisingan)

Hubungkan GitHub ke Slack dengan benar – siapkan integrasi resmi, filter notifikasi berdasarkan label dan branch, dan jaga channel tetap berguna.

By Ellis Keane · 2026-03-19

Sebuah deploy baru saja gagal. Channel Slack tempat tim Anda berkoordinasi sunyi – tidak ada yang melihat peringatan GitHub Actions karena dikirim ke #github-notifications, channel yang semua orang nonaktifkan beberapa minggu lalu.

Jika Anda mencari cara mengintegrasikan GitHub dengan Slack, skenario itu mungkin alasannya. Koneksinya hanya butuh beberapa menit untuk dipasang (saya menyiapkan milik kami di sela-sela rapat sekali, yang ternyata cukup optimistis). Membuatnya benar-benar berguna membutuhkan sedikit lebih lama – dan itulah yang dibahas tutorial ini.

Apa yang dilakukan (dan tidak dilakukan) integrasi resmi GitHub-Slack

Aplikasi Slack resmi GitHub memposting notifikasi tentang PR, issue, deployment, dan commit ke channel Slack. Anda bisa subscribe channel ke repo tertentu, memfilter berdasarkan jenis event, dan melakukan beberapa tindakan langsung dari Slack – menutup issue, membuka yang baru, hal-hal semacam itu.

Yang tidak dilakukannya adalah memahami konteks. Kesalahan ketik di README mendapat perlakuan yang sama dengan hotfix produksi. Pembaruan dependensi yang dibuka oleh bot duduk berdampingan dengan patch keamanan kritis. Integrasi ini adalah pipa, bukan filter – dan pipa hanya berguna jika Anda mengontrol apa yang mengalir melaluinya.

"Integrasi ini adalah pipa, bukan filter – dan pipa hanya berguna jika Anda mengontrol apa yang mengalir melaluinya." – Chris Calo

(Sebagian besar tim menyadari ini sekitar seminggu kemudian, ketika #engineering mulai menyerupai ticker saham untuk commit yang tidak diminta siapapun untuk dilihat.)

Menyiapkan aplikasi GitHub untuk Slack

Tiga langkah, dan Anda sudah siap:

Instal aplikasi GitHub di Slack. Buka direktori aplikasi workspace Slack Anda dan cari "GitHub". Anda memerlukan izin admin workspace, atau setidaknya seseorang yang memilikinya dan berutang budi pada Anda.

Autentikasi. Ketik /github signin di channel mana pun. Ini menghubungkan akun GitHub Anda sehingga Slack dapat menampilkan notifikasi yang lebih kaya dan memungkinkan Anda berinteraksi dengan issue tanpa meninggalkan percakapan.

Subscribe channel ke repo. Di channel tempat Anda ingin menerima notifikasi:

``` /github subscribe owner/repo-name ``` Secara default, ini meng-subscribe Anda ke issues, pulls, commits, releases, dan deployments – lima jenis event, lebih dari yang dibutuhkan sebagian besar channel.

Kurangi segera. Batalkan subscription untuk hal-hal yang tidak melayani channel:

``` /github unsubscribe owner/repo-name commits ``` Untuk kebanyakan tim engineering, pulls dan deployments adalah yang layak dipertahankan. issues tergantung pada apakah tim Anda melakukan triase di GitHub atau menggunakan tracker terpisah seperti Linear. commits hampir selalu kebisingan – jika Anda ingin melihat perubahan kode, lihat PR-nya.

Referensi perintah lengkap ada di docs repo integrasi.

Subscribe dulu, lalu segera batalkan subscription jenis event yang tidak melayani channel. Subscription default "semuanya" adalah alasan mengapa sebagian besar tim akhirnya menonaktifkan channel sepenuhnya.

Cara mengintegrasikan notifikasi GitHub dengan Slack agar benar-benar membantu

Di sinilah sebagian besar tutorial berhenti, dan di sinilah sebagian besar integrasi diam-diam menjadi tidak berguna. Sistem subscribe/unsubscribe ini kasar – semua PR atau tidak ada PR, semua issue atau tidak ada issue. Jika Anda memiliki monorepo dengan empat puluh kontributor, "semua PR" adalah aliran deras yang tak terbendung.

Pemfilteran berbasis label adalah solusi yang kurang dimanfaatkan. Anda bisa memfilter notifikasi berdasarkan label:

``` /github subscribe owner/repo-name +label:"needs-review" ```

Sekarang channel hanya melihat PR atau issue yang diberi tag needs-review. Untuk tim yang menggunakan label secara konsisten (dan itu adalah komitmen nyata, bukan hal sepele), ini mengubah integrasi dari berisik menjadi berguna. PR yang membutuhkan perhatian muncul di Slack. Sisanya tetap di GitHub di mana tempatnya.

Pemfilteran workflow run memungkinkan Anda mempersempit notifikasi CI berdasarkan branch:

``` /github subscribe owner/repo-name workflows +branch:main ```

Ini berarti Anda hanya melihat workflow run yang dipicu di main – bukan setiap CI run dari feature branch. Jika tim Anda menggunakan GitHub Actions untuk deployment, inilah cara mendapatkan peringatan relevan produksi tanpa aliran tanda centang hijau yang terus-menerus dari branch pengembangan.

Arsitektur channel penting. Satu channel #github untuk segalanya adalah resep untuk dinonaktifkan. Pertimbangkan pemisahan:

| Channel | Subscription | |---------|--------------| | #deploys | Hanya deployments | | #pr-reviews | pulls +label:"needs-review" | | #incidents | issues +label:"P0" |

Tiga channel terfokus lebih baik dari satu yang berisik. Masing-masing memiliki tujuan yang jelas, dan anggota tim dapat bergabung dengan yang relevan dengan peran mereka. (Saya tahu ini terdengar jelas, tetapi saya pernah melihat tim dengan satu channel #dev yang menangani bot Slack, notifikasi GitHub, peringatan deployment, dan obrolan umum. Ini kekacauan.)

Tiga alur kerja yang layak dikonfigurasi

Pengingat terjadwal untuk PR yang terbengkalai. Pengingat terjadwal GitHub mengirimkan notifikasi ke Slack ketika PR menunggu review. Anda mengkonfigurasinya melalui UI web GitHub (Settings, lalu Scheduled Reminders), bukan perintah Slack. Ini menangkap PR yang diam-diam menua di backlog karena tidak ada yang memperhatikannya.

Tautan pratinjau deploy. Ketika sebuah PR memicu pratinjau deployment (Vercel, Netlify, atau sejenisnya), statusnya muncul dalam notifikasi Slack. Desainer Anda bisa mengklik URL pratinjau tanpa membuka GitHub – satu peralihan konteks lebih sedikit per review.

Percakapan berbasis thread. Komentar pada notifikasi PR tetap berada dalam thread Slack. "Terlihat bagus, satu catatan kecil di baris 47" Anda terjadi di mana konteks lainnya berada. Komentar tidak disinkronkan kembali ke GitHub (hanya Slack), yang merupakan keterbatasan sekaligus – boleh dikatakan – sebuah fitur.

Ketika integrasi bawaan mencapai batasnya

Integrasi resmi mencakup banyak hal, tetapi ada pola yang tidak dapat ditanganinya:

Visibilitas lintas repo. Jika proyek Anda mencakup tiga repo, Anda memerlukan tiga subscription terpisah dengan tiga konfigurasi filter terpisah. Tidak ada fitur "tampilkan semua yang terkait dengan Proyek X lintas repo." Anda memelihara konfigurasi paralel dan berharap keduanya tetap konsisten.

Menghubungkan GitHub ke issue tracker Anda. Jika tim Anda menggunakan Linear sebagai sumber kebenaran untuk tugas, integrasi GitHub-Slack tidak mengetahui hubungan tersebut. Sebuah PR mungkin menutup issue Linear, tetapi Slack tidak tahu – notifikasi hanya menyebut "PR merged" tanpa konteks tentang tugas apa itu atau siapa yang menunggunya.

Disiplin label dalam skala besar. Pemfilteran berbasis label berhasil, tetapi membutuhkan konsistensi – seseorang harus menerapkan label, dan filter rusak ketika sebuah PR dikirimkan tanpa satu pun. Beban pemeliharaan tumbuh seiring tim. Pada titik tertentu Anda menghabiskan lebih banyak waktu untuk menjaga filter tetap akurat daripada yang Anda hemat dengan memilikinya.

(Inilah saatnya tim beralih ke Zapier atau bot kustom, yang berfungsi hingga autentikasi webhook kedaluwarsa, batas kecepatan mulai berlaku, atau seseorang pergi dan tidak ada yang ingat bagaimana semuanya terhubung.)

Membuatnya bertahan

Integrasi GitHub-Slack adalah salah satu alat yang tidak terlihat (karena dikonfigurasi dengan baik) atau sangat tidak disukai (karena tidak). Perbedaannya ada pada pengaturan:

Subscribe hanya ke jenis event yang melayani tujuan channel
Gunakan filter label dan branch untuk memangkas kebisingan sebelum mencapai Slack
Pisahkan notifikasi ke channel terfokus alih-alih satu channel umum
Siapkan pengingat terjadwal untuk PR yang terbengkalai melalui UI web GitHub
Terima bahwa integrasi bawaan memiliki batasan – dan ketika konteks lintas repo atau koneksi issue tracker penting, lihat alat yang dirancang untuk lapisan itu

Jika Anda perlu mengintegrasikan GitHub dengan Slack, aplikasi bawaan adalah titik awal yang tepat. Tips pemfilteran dan arsitektur channel di atas akan menjaganya tetap berguna melewati minggu pertama. Dan jika Anda telah melampaui kemampuan pipa notifikasi – jika bagian yang hilang adalah hubungan antara PR, tiket Linear yang dimilikinya, dan thread Slack tempat pendekatannya diperdebatkan – itulah yang sedang kami bangun di Sugarbug untuk diselesaikan.

Hubungkan GitHub, Linear, Slack, dan Figma dalam satu grafik pengetahuan – sehingga setiap PR terhubung ke percakapan dan tiket yang menjadi miliknya.

Q: Bagaimana cara mengintegrasikan GitHub dengan Slack? A: Instal aplikasi GitHub dari direktori aplikasi Slack, autentikasi dengan /github signin, lalu subscribe channel ke repo dengan /github subscribe owner/repo-name. Kurangi jenis event segera – default menyertakan semuanya, yang hampir selalu terlalu berisik.

Q: Bisakah Sugarbug menggantikan integrasi GitHub-Slack? A: Sugarbug bekerja berdampingan dengannya, bukan menggantikannya. Integrasi bawaan menangani notifikasi; Sugarbug membangun grafik pengetahuan yang menghubungkan PR GitHub ke issues Linear yang sesuai, diskusi Slack, dan desain Figma – sehingga Anda melihat konteks lengkap dari sebuah perubahan, bukan hanya bahwa PR telah di-merge.

Q: Bagaimana cara memfilter notifikasi GitHub di Slack berdasarkan label? A: Gunakan filter label saat subscribe: /github subscribe owner/repo-name +label:"needs-review". Hanya item dengan label tersebut yang akan diposting ke channel. Anda bisa menggabungkan beberapa filter label dan mencampurnya dengan subscription jenis event.

Q: Apakah Sugarbug melacak aktivitas GitHub di Slack dan Linear secara otomatis? A: Ya. Sugarbug terhubung ke GitHub, Slack, dan Linear melalui API dan mengkorelasikan aktivitas – ketika PR GitHub mereferensikan percakapan Slack atau menutup tiket Linear, koneksi tersebut dilacak dalam grafik pengetahuan tanpa penandaan manual atau disiplin label.