踩雷筆記：Deploy Hooks 沒反應？原來是 main 和 master 在搞鬼！（附完整遷移教學）

03 December 2025
Git,
GitHub,
CI/CD,
Deploy Hooks,
Ian Chou

踩雷筆記：Deploy Hooks 沒反應？原來是 main 和 master 在搞鬼！（附完整遷移教學）

你是否曾經遇過這種情況？

CI/CD 腳本寫得完美無缺，Deploy Hook 的 URL 也填好了，代碼一推上去 (Git Push)，結果... 一片死寂。沒有報錯，但也沒有觸發任何動作。

我最近就為了這個問題 Debug 了好久，懷疑過權限、檢查過 curl 指令，最後發現兇手竟然是最基礎的 「分支名稱」。這篇文章就是為了提醒大家（還有未來的我自己）：在設定自動化流程時，千萬別忽略了 main 與 master 的差異！

💣 問題現場：代碼推了，Action 卻睡著了

場景是這樣的：我正在設定一個「子站更新後，自動觸發主站重建」的流程。我在子站的 GitHub Actions (deploy.yml) 中寫下了這段配置：

name: Deploy

on:
  push:
    # 這裡就是陷阱所在！
    branches: [main]

jobs:
  deploy:
    # ... (省略部署與觸發 Hook 的步驟) ...

看起來很標準，對吧？但我推送代碼後，GitHub Actions 完全沒有反應。Workflow 根本沒有跑起來。

🔍 真相大白

經過一番折騰，我抬頭看了一眼我的 Terminal，才發現問題所在：

(master) $ git push origin master

我的 Repo 是 master 分支，但我的 YAML 檔裡監聽的卻是 main 分支！

為什麼會有這種混亂？

這要追溯到 Git 和 GitHub 的一段歷史演變：

舊時代：Git 的預設分支名稱一直是 master。
變革 (2020 年起)：為了響應平權運動（消除 master/slave 用語），GitHub 將新儲存庫的預設分支改為 main。
現狀：導致新舊專案混雜。如果你在本地用舊版 Git 初始化 (git init)，可能是 master；但在 GitHub 網頁新建 Repo 卻是 main。

一旦你的 CI/CD 設定檔寫死 branches: [main]，而你的舊專案還停留在 master，整個自動化流程就會直接被「無視」。

🛠️ 解決方案：手動無痛遷移三部曲

既然發現了問題，建議乾脆將舊專案一次遷移到 main，讓所有專案保持一致，避免未來再次踩雷。

為了確保遷移過程平順，請依照以下 「GitHub 改名 -> 本地同步 -> 部署平台設定」 的順序操作：

第一階段：在 GitHub 網站上改名

這是最簡單的起手式，先讓遠端變成正確的狀態。

進入你的 GitHub Repository 頁面。
點擊 Settings -> General。
找到 Default branch 區塊。
點擊鉛筆圖示（Rename），將 master 改為 main 並確認。

第二階段：讓本地端跟上 (Terminal 指令)

GitHub 改完後，你的本地端電腦還停留在舊資訊，這時候需要執行以下指令來同步。這套指令非常穩健，能確保追蹤關係正確建立：

# 1. 先將本地的 master 分支重新命名為 main
git branch -m master main

# 2. 抓取遠端最新的狀態 (這時候遠端已經有 main 了)
git fetch origin

# 3. 將本地的 main 分支與遠端的 origin/main 建立追蹤關係
git branch -u origin/main main
# 顯示: branch 'main' set up to track 'origin/main'.

# 4. 更新本地的 HEAD 指標，確保它指向正確的遠端分支
git remote set-head origin -a
# 顯示: 'origin/HEAD' has changed from 'master' and now points to 'main'

第三階段：別忘了部署平台！(最重要的一步)

這一步最容易被遺忘！即使 GitHub 改好了，你的部署平台可能還在傻傻地等 master 分支的更新，導致網站一直沒變。

請到你的 hosting 平台（如 Cloudflare Pages, Vercel, Netlify）：

進入專案的 Settings。
找到 Git 或 Build & Deploy 相關設定。
將 Production Branch 從 master 修改為 main。
儲存設定。

如果你的主站（或會被子站觸發重建的那個 Repo）以前是從 master 部署，後來也改成 main，記得順便把舊的 Deploy Hooks / Webhooks 清理或重建一次，避免它們還在監聽 master：

Cloudflare Pages：到專案的 Deploy Hooks 區塊，刪除仍綁定 master 的 Hook，重新建立指向 main 的 Hook。
Vercel：到 Settings → Git / Deploy Hooks，把對 master 的 Hook 刪掉或改為 main。
Netlify：到 Site settings → Build & deploy → Build hooks，將指向 master 的 Hooks 清除或改成 main。

否則未來如果不小心又推到 master，這些 Hooks 仍可能被觸發，造成多餘部署或狀態混亂。

💡 同場加映：一勞永逸的設定

為了避免以後在本地 git init 時又跑出 master，建議修改全域設定，跟上現代標準：

git config --global init.defaultBranch main

📝 總結

Deploy Hook 沒反應？CI/CD 沒觸發？ 先別急著懷疑你的程式碼，請先檢查這三件事：

你的 YAML 寫的是 main 還是 master？
你的 Repo 實際跑的是 main 還是 master？
你的 Vercel/Cloudflare 監聽的是哪一個分支？

一個小小的名稱差異，可能會讓你浪費好幾個小時 Debug。花一分鐘統一成 main，省下的時間拿去喝杯咖啡吧！