GitHub Actions + Notion API：Commit 同步到 Notion — 編譯摘要
濃縮
核心結論
- 透過 [[GitHub Actions]] 監聽 dev 分支的 push 事件，用 curl 打 Notion API 即可實現 commit 紀錄自動同步，不需要第三方服務，設定約十分鐘。
- Notion Integration 建好後必須手動將資料庫 Share 給 Integration（給 Can edit 權限），否則 API 會回 403。這是最常被遺漏的步驟。
- commit message 中的特殊字元（引號、換行）需要 JSON 跳脫處理，否則 API 請求的 JSON 會壞掉。
關鍵證據
- Workflow 僅需一個 step：用 curl + Python JSON 跳脫，直接呼叫 Notion API 建立 page。
- Database ID 容易與 View ID（
?v= 後面的值）搞混。
- force push / rebase 會導致重複寫入，需額外用 Notion filter API 做去重。
質疑
依賴哪些前提假設？
- 假設團隊使用 Notion 做專案管理。
- 假設 commit message 品質足夠好，同步到 Notion 後有參考價值。
- 假設 Notion API 的穩定性與速率限制不會造成問題（Notion API rate limit 為 3 req/s）。
換產業/規模/技術棧還成立嗎？
- 相同概念可替換為其他工具組合：GitLab CI + Jira API、Bitbucket Pipelines + Linear API 等。
- 大型團隊的 commit 量可能很大，每次 push 都寫 Notion 可能衝擊 API 限制。
- monorepo 環境需要調整 REPO 變數的設計。
反例或邊界條件
- squash merge 時，GitHub 的
head_commit 只有合併後的那一筆，原始的多筆 commit 會遺失。
- 如果 Notion token 過期且沒有告警機制，同步會靜默失敗。
對標
其他領域的類似現象
- 會計業的日記帳自動化：每筆交易自動記錄到帳冊，與 commit 自動同步到 Notion 同理。
- 物流業的貨物追蹤：每個節點狀態自動更新到中央系統。
知識可遷移到哪些場景
- 任何「事件驅動 → 寫入外部系統」的 [[Webhook 整合]]模式。
- 部署紀錄同步、PR 狀態同步、issue 狀態同步等 DevOps 自動化場景。
關聯概念
- [[GitHub Actions]]
- [[Webhook 整合]]
- [[Notion API]]
- [[DevOps 自動化]]
- [[事件驅動架構]]
![]()