無干擾整合 GitHub 與 Slack
正確連接 GitHub 與 Slack – 設定官方整合，透過標籤與分支過濾通知，讓頻道保持實用。
By Chris Calo · 2026-03-19
剛剛一個 deploy 失敗了。你們團隊平常協作的 Slack 頻道卻一片安靜 – 沒人看到 GitHub Actions 的警報，因為它被發到了 #github-notifications，一個大家幾週前就全員靜音的頻道。
如果你正在查如何整合 GitHub 與 Slack，大概就是因為遇到這種情境。安裝連線只需要幾分鐘（我有次在兩個會議的空檔搞定設定，事後回想還挺樂觀的）。但要讓它真正發揮作用需要多花點時間，這篇教學就是在講這件事。
官方 GitHub-Slack 整合能做什麼（以及不能做什麼）
GitHub 的官方 Slack App 會把 PR、issue、部署和 commit 的通知發到 Slack 頻道中。你可以讓頻道訂閱特定的 repo，依事件類型過濾，還能直接在 Slack 裡做一些操作 – 像是關閉 issue、開新的 issue 之類的。
但它做不到的是理解脈絡。README 裡的 typo 修正，跟 production hotfix 通知的權重完全一樣。Bot 自動開的 dependency bump，會跟重大安全修補並列在一起。這個整合本質上是管線，不是過濾器 – 而管線好不好用，取決於你能不能控制流進來的是什麼。
"這個整合本質上是管線，不是過濾器 – 而管線好不好用，取決於你能不能控制流進來的是什麼。" – Chris Calo
（多數團隊大概用了一週就會發現這件事，因為 #engineering 頻道已經變得像股票跑馬燈，塞滿了根本沒人想看的 commit 通知。）
在 Slack 設定 GitHub App
三個步驟就搞定：
- 在 Slack 安裝 GitHub App。 到你們 Slack 工作區的應用程式目錄搜尋「GitHub」。你需要工作區管理員權限，或至少找個有權限且欠你人情的人幫忙。
- 身分驗證。 在任何頻道輸入
/github signin。這會連結你的 GitHub 帳號，讓 Slack 能顯示更豐富的通知，也讓你不離開對話就能操作 issue。
- 讓頻道訂閱 repo。 在你想接收通知的頻道輸入：
``` /github subscribe owner/repo-name ``` 預設情況下，這會訂閱 issues、pulls、commits、releases 和 deployments – 五種事件類型，對大多數頻道來說太多了。
- 立刻精簡。 退訂對該頻道沒用的事件：
``` /github unsubscribe owner/repo-name commits ``` 對多數工程團隊來說，pulls 和 deployments 是最值得保留的。issues 要看你們團隊是在 GitHub 裡做分類（triage），還是使用像 Linear 這類獨立的追蹤工具。commits 幾乎都是雜訊 – 真要看程式碼變更，直接看 PR 就好。
完整的指令參考在整合 repo 的文件中。
先訂閱，再立刻退掉對頻道沒用的事件類型。預設的「全部訂閱」正是多數團隊最後把整個頻道靜音的主因。
如何整合 GitHub 與 Slack，讓通知真正幫上忙
大多數教學到這裡就結束了，這也是多數整合默默變得毫無用處的起點。subscribe/unsubscribe 系統太粗糙 – 不是收全部 PR 就是全不收，不是收全部 issue 就是全不收。如果你們的 monorepo 有四十個 contributor，「全部 PR」基本就是消防水柱直噴。
基於標籤的過濾是目前最實用的解法，但卻很少人善用。你可以透過標籤來過濾通知：
``` /github subscribe owner/repo-name +label:"needs-review" ```
這樣頻道只會看到標記了 needs-review 的 PR 或 issue。對於有紀律在使用標籤的團隊來說（這需要真正的承諾，絕對不是小事），這能讓整合從充滿雜訊變得真正實用。需要關注的 PR 會浮現在 Slack 中，其他的就乖乖留在 GitHub 裡。
工作流程執行過濾讓你可以依分支來縮小 CI 通知的範圍：
``` /github subscribe owner/repo-name workflows +branch:main ```
這代表你只會看到在 main 上觸發的工作流程執行結果 – 不是每個 feature branch 的 CI 執行。如果你們團隊用 GitHub Actions 做部署，這就是在不被開發分支一連串綠色勾勾洗版的情況下，取得 production 相關警報的方法。
頻道架構很重要。 把所有東西都塞進單一的 #github 頻道，絕對是被全員靜音的配方。考慮這樣拆分：
| 頻道 | 訂閱內容 | |---------|--------------| | #deploys | 僅限 deployments | | #pr-reviews | pulls +label:"needs-review" | | #incidents | issues +label:"P0" |
三個聚焦的頻道絕對勝過一個吵鬧的頻道。每個頻道都有明確的目的，團隊成員可以加入與自己角色相關的頻道。（我知道這聽起來很理所當然，但我看過有團隊只用一個 #dev 頻道來處理 Slack 機器人、GitHub 通知、部署警報還有日常閒聊。那根本是場災難。）
三個值得設定的工作流程
閒置 PR 的排程提醒。 當有 PR 正在等待 review 時，GitHub 的排程提醒會發送提醒到 Slack。你需要透過 GitHub 的網頁介面來設定（進入 Settings，然後選擇 Scheduled Reminders），而不是用 Slack 指令。這能抓出那些因為沒人注意到，而在 backlog 裡默默積灰的 PR。
部署預覽連結。 當 PR 觸發部署預覽（Vercel、Netlify 或類似工具）時，狀態會顯示在 Slack 通知中。設計師不用打開 GitHub 就能直接點擊預覽網址 – 每次 review 都少一次情境切換。
基於討論串的對話。 對 PR 通知的留言會留在 Slack 討論串裡。你那句「看起來不錯，只有第 47 行有個小地方」就會出現在其他脈絡所在的地方。這些留言不會同步回 GitHub（僅限 Slack），這算是個限制，但換個角度來看，也是個特色。
當原生整合遇到瓶頸
官方整合涵蓋了很多層面，但有些使用情境它處理不了：
跨 repo 的可見度。 如果你的專案橫跨三個 repo，你需要三個獨立的訂閱和三套獨立的過濾設定。沒有那種「顯示跨 repo 且與專案 X 相關的所有內容」的功能。你只能維護平行的設定，並祈禱它們保持一致。
將 GitHub 連接到你的任務追蹤工具。 如果你們團隊把 Linear 當作任務的單一事實來源（source of truth），GitHub-Slack 整合對這層關係一無所知。一個 PR 可能會關閉一個 Linear issue，但 Slack 不知道 – 通知只會寫「PR 已合併」，完全沒有脈絡告訴你這是為了解決哪個任務，或是誰正在等它。
大規模下的標籤紀律。 基於標籤的過濾確實有效，但需要一致性 – 必須有人去貼標籤，只要有一個 PR 沒貼標籤就發布了，過濾器就會失效。維護成本會隨著團隊規模增長。到某個階段，你會發現花在維持過濾器準確性上的時間，已經超過它幫你省下的時間了。
（這通常是團隊開始找 Zapier 或自建機器人的時候，一開始有效，直到 webhook 驗證跑掉、觸發 API 速率限制，或是當初串接的人離職後沒人記得這東西到底怎麼接的。）
讓它真正持續發揮作用
GitHub-Slack 整合就是那種要嘛「隱形」（因為設定得很好），要嘛「被大家討厭」（因為設定得爛）的工具。差別就在設定方式：
- 只訂閱符合頻道目的的事件類型
- 用標籤和分支過濾器，在雜訊進入 Slack 之前就先攔截
- 把通知拆分到聚焦的頻道，而不是一個大雜燴全包
- 透過 GitHub 網頁介面為閒置的 PR 設定排程提醒
- 接受原生整合有其極限 – 當跨 repo 的脈絡或任務追蹤工具的連結變得重要時，去找專為那個層級設計的工具
如果你需要整合 GitHub 與 Slack，原生 App 是個很好的起點。上面提到的過濾技巧和頻道架構，能讓它在第一週的新鮮期過後依然實用。而如果你已經超越了一根通知管線能做到的事 – 如果缺少的那塊拼圖是 PR、它所屬的 Linear 票券（ticket），以及當初討論做法的 Slack 討論串之間的關聯 – 那正是我們打造 Sugarbug 要解決的問題。
The GitHub-Slack pair is one piece of a unified workflow across Linear, GitHub, Figma, and Slack – that article covers all six pairwise connections. For the Slack side of the tracker relationship, keeping Slack and Linear in step covers the native integration setup and channel-mapping decisions in detail. The design side of the notification problem is described in bridging Figma comments and Linear issues.
將 GitHub、Linear、Slack 和 Figma 整合進同一張知識圖譜 – 讓每個 PR 都能連結到它所屬的對話和票券。
Q: 如何將 GitHub 與 Slack 整合？ A: 從 Slack 的應用程式目錄安裝 GitHub App，使用 /github signin 進行身分驗證，接著用 /github subscribe owner/repo-name 讓頻道訂閱 repo。請務必立刻精簡事件類型 – 預設值會包含所有通知，幾乎一定太吵。
Q: Sugarbug 可以取代 GitHub-Slack 整合嗎？ A: Sugarbug 是與其並行運作的，而不是取代它。原生整合負責處理通知；Sugarbug 則建立知識圖譜，把 GitHub PR 串到對應的 Linear 任務、Slack 討論和 Figma 設計 – 讓你看到變更的完整脈絡，而不只是 PR 被合併的通知。
Q: 如何在 Slack 中透過標籤過濾 GitHub 通知？ A: 訂閱時使用標籤過濾器：/github subscribe owner/repo-name +label:"needs-review"。只有具備該標籤的項目才會發布到頻道中。你可以組合多個標籤過濾器，並將它們與事件類型訂閱混合使用。
Q: Sugarbug 會自動追蹤跨 Slack 與 Linear 的 GitHub 活動嗎？ A: 會。Sugarbug 透過 API 連接 GitHub、Slack 與 Linear，並關聯它們之間的活動 – 當 GitHub PR 提及 Slack 對話或關閉 Linear 票券時，這些連結會自動記錄在知識圖譜中，無需手動標記或維持標籤紀律。