🆓 完全免費
Public Repo 可免費使用 GitHub Pages,自動提供 username.github.io 網域。
GitHub 不只是放程式碼的地方——你可以用 GitHub Pages 免費部署靜態網站,用 Actions 自動化測試與部署流程,還有更多進階功能幫助你提升開發效率。
GitHub Pages 讓你直接從 GitHub Repository 部署靜態網站,完全免費。適合個人網站、專案文件、作品集與教學教材。
Public Repo 可免費使用 GitHub Pages,自動提供 username.github.io 網域。
每次 push 到指定分支,GitHub 會自動重新建置並部署你的網站。
支援自訂網域名稱(Custom Domain),並自動提供 HTTPS 憑證。
根據你的需求選擇最適合的方式。
最簡單的方式——將整個 main 分支的根目錄作為網站。
index.html。# 網站 URL 格式
https://<username>.github.io/<repo-name>/
# 範例
https://alice.github.io/my-portfolio/
適合程式碼與文件分開管理——只部署 docs/ 資料夾的內容。
my-project/
├── src/ ← 程式碼(不會被部署)
├── docs/ ← 網站內容(會被部署)
│ ├── index.html
│ ├── style.css
│ └── guide.html
├── README.md
└── package.json
docs/ 資料夾中。最靈活的方式——用 GitHub Actions 自訂建置流程。適合需要編譯的框架(如 React、Vue、Jekyll)。
.github/workflows/deploy.yml。(詳見本章後半的 Actions 段落。)
| 項目 | 限制 |
|---|---|
| Repo 大小 | 建議不超過 1 GB |
| 網站大小 | 不超過 1 GB |
| 每月流量 | 100 GB soft limit |
| 建置頻率 | 每小時最多 10 次 |
| 支援內容 | 僅靜態內容(HTML/CSS/JS),無法執行後端程式 |
# 建立專案
$ mkdir my-site && cd my-site
$ git init
# 建立簡單的網頁
$ cat > index.html <<'EOF'
<!DOCTYPE html>
<html lang="zh-Hant">
<head>
<meta charset="utf-8">
<title>我的第一個 GitHub Pages 網站</title>
<style>
body { font-family: sans-serif; max-width: 600px; margin: 2rem auto; padding: 0 1rem; }
h1 { color: #f05033; }
</style>
</head>
<body>
<h1>Hello, GitHub Pages!</h1>
<p>這是我用 Git 部署的第一個網站。</p>
</body>
</html>
EOF
$ git add . && git commit -m "feat: 建立首頁"
# 在 GitHub 建立一個新的 Public Repo(名稱如 my-site)
# 連結遠端並推送
$ git remote add origin git@github.com:你的帳號/my-site.git
$ git push -u origin main
GitHub Actions 是 GitHub 內建的 CI/CD(持續整合 / 持續部署)平台。它能在特定事件發生時(如 push、PR 建立)自動執行你定義的工作流程——從跑測試、檢查程式碼品質,到自動部署網站或發布套件,全部都能自動完成。
CI(Continuous Integration,持續整合):每次提交程式碼後,自動執行測試,確保新程式碼不會破壞現有功能。
CD(Continuous Deployment,持續部署):測試通過後,自動部署到正式環境,不需人工介入。
理解 GitHub Actions 的關鍵在於搞清楚六個核心概念的層級關係。下面的架構圖展示了它們如何組合在一起:
| 概念 | 說明 | 類比 |
|---|---|---|
| Workflow | 一個自動化流程,定義在 .github/workflows/ 目錄下的 YAML 檔案中。 |
一份「自動化劇本」 |
| Event | 觸發 workflow 的事件,如 push、pull_request、schedule(定時)。 |
開演的「鈴聲」 |
| Job | workflow 中的一組任務。多個 job 預設平行執行,也可設定依賴順序。 | 劇本中的「幕」 |
| Step | job 中的單一步驟,可以執行指令或使用別人寫好的 Action。 | 每一幕中的「台詞或動作」 |
| Action | 可重用的步驟模組,GitHub Marketplace 上有數千個現成的 Action 可用。 | 預先排練好的「表演套路」 |
| Runner | 執行 workflow 的虛擬機器。GitHub 提供免費的 Ubuntu、macOS、Windows runner。 | 表演的「舞台」 |
Workflow 是 GitHub Actions 的最上層單位,一個 YAML 檔案就是一個 workflow。每個 Repo 可以有多個 workflow,各自獨立運作。
所有 workflow 檔案都放在 .github/workflows/ 目錄下,檔名自訂(如 ci.yml、deploy.yml)。
使用 YAML(.yml / .yaml)格式撰寫,注意縮排很重要——使用空格而非 Tab。
# 一個 Repo 可以有多個 workflow,各司其職:
my-project/
└── .github/
└── workflows/
├── ci.yml ← 每次 push 時跑測試
├── deploy.yml ← main 分支更新時自動部署
├── release.yml ← 建立 tag 時自動發行
└── weekly-check.yml ← 每週定時檢查依賴更新
# .github/workflows/ci.yml
name: CI Pipeline # ① workflow 名稱(顯示在 Actions 頁面)
on: # ② 觸發條件(Event)
push:
branches: [ main ]
jobs: # ③ 定義 Job
test: # Job ID(自訂名稱)
runs-on: ubuntu-latest # ④ 選擇 Runner
steps: # ⑤ 定義 Steps
- uses: actions/checkout@v4
- run: npm test
name:、一個 on: 和一個 jobs: 區塊。但 jobs: 底下可以定義多個 Job。
Event 決定了「什麼時候」啟動 workflow。GitHub 支援超過 30 種事件類型,以下是最常用的幾種:
| 事件類型 | 觸發時機 | 常見用途 |
|---|---|---|
push |
有人 push 程式碼到指定分支時 | 跑測試、自動部署 |
pull_request |
PR 被建立、更新或重新開啟時 | 程式碼審查前的自動檢查 |
schedule |
按照 cron 排程定時執行 | 每日備份、定時更新資料 |
workflow_dispatch |
在 GitHub 網頁上手動點擊觸發 | 手動部署、除錯用途 |
release |
建立或發布 Release 時 | 自動打包、發布套件 |
issues |
Issue 被建立、標記或關閉時 | 自動分類、通知 |
你可以用 branches、paths、types 等參數縮小觸發範圍,避免不必要的執行:
只在特定條件下才觸發 workflow。
# 只在 push 到 main 或 release/* 分支時觸發
on:
push:
branches:
- main
- 'release/**'
pull_request:
branches:
- main # 只有目標為 main 的 PR 才觸發
使用 branches 參數限定觸發的分支。支援 glob 模式(*、**)。
# 只在 src/ 目錄的程式碼變更時才跑測試
on:
push:
paths:
- 'src/**'
- 'tests/**'
paths-ignore:
- '**.md' # 修改文件不觸發
- '.github/**' # 修改 workflow 不觸發
使用 paths 只在特定目錄有變更時觸發,搭配 paths-ignore 排除不相關的變更。
# 每週一早上 9 點(UTC)自動執行
on:
schedule:
- cron: '0 9 * * 1'
# cron 語法:分 時 日 月 星期
# ┌──── 分鐘 (0-59)
# │ ┌──── 小時 (0-23)
# │ │ ┌──── 日 (1-31)
# │ │ │ ┌──── 月 (1-12)
# │ │ │ │ ┌──── 星期 (0-6,0=週日)
# │ │ │ │ │
# * * * * *
# 更多範例:
# '0 0 * * *' → 每天午夜
# '30 8 * * 1-5' → 週一到週五 08:30
# '0 */6 * * *' → 每 6 小時
# 在 GitHub 網頁上手動觸發,可帶自訂參數
on:
workflow_dispatch:
inputs:
environment:
description: '部署目標環境'
required: true
default: 'staging'
type: choice
options:
- staging
- production
debug:
description: '啟用除錯模式'
required: false
type: boolean
default: false
workflow_dispatch 讓你可以在 Actions 頁面上按下 Run workflow 按鈕手動觸發,還能傳入自訂參數。
Job 是 Workflow 中的「任務單位」。一個 Workflow 可以包含多個 Job,預設會平行(parallel)執行,但也可以用 needs 設定依賴順序。
| 屬性 | 說明 | 範例 |
|---|---|---|
runs-on |
指定 Runner 的作業系統 | ubuntu-latest、macos-latest、windows-latest |
needs |
定義依賴關係,指定此 Job 必須等哪些 Job 完成 | needs: [build, test] |
if |
條件判斷,符合條件才執行 | if: github.ref == 'refs/heads/main' |
strategy.matrix |
矩陣策略,自動展開多組執行 | 同時在多個 Node.js 版本上測試 |
environment |
綁定部署環境,可設定審核與 secrets | environment: production |
outputs |
將 Job 的輸出傳遞給下游 Job | outputs: { version: ${{ steps.ver.outputs.v }} } |
從基礎到進階的 Job 設定方式。
jobs:
# Job 1: 執行測試(先跑)
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
# Job 2: 建置(test 完成後才跑)
build:
needs: test # ← 等 test 完成
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm run build
# Job 3: 部署(build 完成後才跑)
deploy:
needs: build # ← 等 build 完成
runs-on: ubuntu-latest
steps:
- run: echo "Deploying..."
使用 needs 建立 test → build → deploy 的依序執行流程。如果 test 失敗,後續 Job 都不會執行。
jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
node-version: [18, 20, 22]
# 這會自動產生 3×3 = 9 個 Job 組合!
steps:
- uses: actions/checkout@v4
- name: 設定 Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
- run: npm ci
- run: npm test
矩陣策略會自動展開所有組合,上面的範例會同時跑 9 個 Job(3 個 OS × 3 個 Node 版本),確保你的程式碼在各種環境都能正常運作。
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm test
# 只在 main 分支、且 test 通過後才部署
deploy:
needs: test
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
steps:
- run: echo "只有 push 到 main 才會跑到這裡"
# 即使前面的 Job 失敗也要執行的清理工作
cleanup:
needs: [test, deploy]
runs-on: ubuntu-latest
if: always() # ← 不管前面是否失敗都執行
steps:
- run: echo "清理暫存資源..."
if 條件可以使用 github context(如分支名、事件類型)來決定是否執行。always() 表示無論前面 Job 是否失敗都會執行。
Step 是 Job 中最小的執行單位。每個 Step 依序(sequential)執行,前一個 Step 失敗時,後面的 Step 預設不會繼續。
run: — 執行指令直接執行一行或多行 shell 指令,就像你在終端機裡打指令一樣。
steps:
# 單行指令
- name: 顯示目錄
run: ls -la
# 多行指令(用 | 符號)
- name: 安裝與測試
run: |
npm ci
npm run build
npm test
uses: — 使用 Action引用別人(或官方)已經寫好的可重用 Action,避免自己重寫常見邏輯。
steps:
# 引用官方 Action
- name: Checkout 程式碼
uses: actions/checkout@v4
# 引用帶參數的 Action
- name: 設定 Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
| 屬性 | 說明 | 範例 |
|---|---|---|
name |
步驟名稱,顯示在 Actions 執行日誌中 | name: 執行單元測試 |
run |
執行 shell 指令 | run: npm test |
uses |
使用外部 Action | uses: actions/checkout@v4 |
with |
傳遞參數給 Action | with: { node-version: '20' } |
env |
設定這個 Step 的環境變數 | env: { NODE_ENV: production } |
if |
條件判斷,符合才執行 | if: success()、if: failure() |
id |
步驟 ID,供後續 Step 引用輸出 | id: get-version |
continue-on-error |
即使此步驟失敗,也繼續執行後面的步驟 | continue-on-error: true |
steps:
# Step 1: 取得版本號並輸出
- name: 取得版本號
id: get-version # ← 給這個 Step 一個 ID
run: |
VERSION=$(cat package.json | jq -r '.version')
echo "version=$VERSION" >> $GITHUB_OUTPUT # ← 寫入輸出
# Step 2: 使用上一步的輸出
- name: 顯示版本號
run: echo "目前版本是 ${{ steps.get-version.outputs.version }}"
# ↑ 透過 steps.{id}.outputs.{key} 讀取
$GITHUB_OUTPUT 檔案傳遞資料。格式為 key=value,在下游 Step 用 ${{ steps.{id}.outputs.{key} }} 讀取。
Action 是 GitHub Actions 生態系的核心——它是可重用的步驟模組,把常見的操作封裝起來,讓你不用從頭寫每一個步驟。
GitHub Marketplace 上有超過 20,000 個免費的社群 Action,涵蓋測試、部署、通知等各種需求。
actions/ 開頭的 Action 由 GitHub 官方維護,品質穩定、安全性有保障。
使用 @v4 指定大版本,確保你的 workflow 不會因為 Action 更新而突然壞掉。
# 使用公開的 Action(最常見)
- uses: owner/repo@version # 格式:帳號/專案@版本
- uses: actions/checkout@v4 # 範例:官方的 checkout
- uses: actions/setup-node@v4 # 範例:官方的 Node.js 設定
# 使用同一個 Repo 中的本地 Action
- uses: ./.github/actions/my-action
# 使用 Docker Hub 上的 Image
- uses: docker://alpine:3.18
| Action | 用途 | 說明 |
|---|---|---|
actions/checkout@v4 |
拉取程式碼 | 幾乎每個 workflow 的第一步——把 Repo 的程式碼下載到 Runner 上。 |
actions/setup-node@v4 |
設定 Node.js | 安裝指定版本的 Node.js,支援快取 npm 依賴。 |
actions/setup-python@v5 |
設定 Python | 安裝指定版本的 Python,支援快取 pip 依賴。 |
actions/upload-artifact@v4 |
上傳產出物 | 將 build 產物、測試報告等上傳為 Artifact,供其他 Job 或人員下載。 |
actions/download-artifact@v4 |
下載產出物 | 在下游 Job 中下載上游 Job 上傳的 Artifact。 |
actions/cache@v4 |
快取依賴 | 快取 node_modules、.pip 等,加速後續執行。 |
actions/configure-pages@v4 |
設定 Pages | 搭配 deploy-pages 用於 GitHub Pages 部署。 |
actions/)或知名組織維護的 Action。@v4 而非 @main),避免不預期的變更。Runner 是實際執行 Job 的虛擬機器。每個 Job 都會在一台全新的 Runner 上啟動,執行完畢後銷毀——這保證了每次執行都是乾淨的環境。
由 GitHub 提供和管理的雲端虛擬機。免安裝、免維護,開箱即用。
在你自己的伺服器上安裝 Runner 軟體,連線到 GitHub 執行 workflow。
| Runner 標籤 | 作業系統 | vCPU | 記憶體 | 儲存空間 | 費率倍數 |
|---|---|---|---|---|---|
ubuntu-latest |
Ubuntu 22.04 / 24.04 | 4 | 16 GB | 14 GB SSD | 1x(基準) |
macos-latest |
macOS 14 (Sonoma) | 3 (M1) | 7 GB | 14 GB SSD | 10x |
windows-latest |
Windows Server 2022 | 4 | 16 GB | 14 GB SSD | 2x |
ubuntu-latest:可以跑 2,000 分鐘。windows-latest:只能跑 1,000 分鐘(2x 費率,消耗雙倍額度)。macos-latest:只能跑 200 分鐘(10x 費率)。ubuntu-latest 最划算。
Git、curl、wget、jq、Docker、Docker Compose
Node.js、Python、Ruby、Go、Java、.NET、Rust
AWS CLI、Azure CLI、Google Cloud CLI、GitHub CLI (gh)
前面提到 Runner 是一台「虛擬機器」,但虛擬機器到底是什麼?為什麼 GitHub 選擇用 VM 來跑 CI/CD?這個概念不只在 GitHub Actions 中出現——它是現代雲端運算的基石。
虛擬機器是透過軟體模擬出來的完整電腦,擁有自己的 CPU、記憶體、硬碟和作業系統。它跑在一台實體電腦(Host)上,但對內部的程式來說,它就像一台獨立的真實電腦。
關鍵技術:Hypervisor(虛擬機器管理程式)——負責在實體硬體上建立和管理多台虛擬機器。
把實體伺服器想像成一棟大樓:
Docker 容器是另一種虛擬化技術,但它和 VM 有根本性的差異:
| 比較項目 | 虛擬機器(VM) | 容器(Container) |
|---|---|---|
| 隔離程度 | 完全隔離(各自有獨立 OS) | 共用 Host OS 核心,隔離性較低 |
| 啟動速度 | 分鐘級(需開機一整個 OS) | 秒級(只啟動應用程式的進程) |
| 資源占用 | 大(每台 VM 都要一份完整 OS,通常 GB 級) | 小(共用 OS,只包含 App + 依賴,通常 MB 級) |
| 可攜性 | 有限(VM 映像檔通常很大) | 優秀(Docker Image 易於分享與遷移) |
| 安全性 | 高(硬體級隔離,難以突破) | 中(共用核心,理論上有逃逸風險) |
| 適用場景 | 需要完全隔離、不同 OS、高安全性 | 微服務架構、快速部署、開發環境統一 |
AWS EC2、Google Compute Engine、Azure VM 本質上都是在賣虛擬機器。你「租」一台 VM,按小時或秒計費。
GitHub Actions Runner、GitLab Runner、Jenkins Agent 都使用 VM 來提供乾淨的建置環境——就是我們正在學的。
用 VirtualBox 或 Parallels 在 Mac 上跑 Windows、在 Windows 上跑 Linux,測試跨平台相容性。
企業將一台強大的實體伺服器分割成多台 VM,分別跑不同服務(Web Server、Database、Mail Server)。
在 VM 中開啟可疑檔案或測試惡意程式,即使 VM 被攻陷也不影響 Host。(沙盒 Sandbox 概念)
VM 支援「快照」功能——隨時儲存狀態,出問題時一鍵還原。這在測試環境中非常實用。
學完六大概念後,讓我們用一個完整的範例把它們串起來:
# 把六大概念對應到完整範例:
name: Complete CI/CD # ← Workflow 名稱
on: # ← Event
push:
branches: [ main ]
jobs:
test: # ← Job
runs-on: ubuntu-latest # ← Runner
steps: # ← Steps
- uses: actions/checkout@v4 # ← Action(可重用模組)
- run: npm ci # ← Step(shell 指令)
- run: npm test
deploy:
needs: test # ← Job 依賴
runs-on: ubuntu-latest
if: success()
steps:
- uses: actions/checkout@v4
- uses: actions/configure-pages@v4
- uses: actions/upload-pages-artifact@v3
with:
path: './dist'
- uses: actions/deploy-pages@v4
Workflow 使用 YAML 格式定義,存放在 .github/workflows/ 目錄下。
從簡單到實用的三個範例。
# .github/workflows/hello.yml
name: Hello World
on:
push:
branches: [ main ]
jobs:
greet:
runs-on: ubuntu-latest
steps:
- name: Say Hello
run: echo "Hello from GitHub Actions!"
- name: Show Date
run: date
- name: Show Git Version
run: git --version
每次 push 到 main 分支時,這個 workflow 會在 Ubuntu 虛擬機上執行三個指令。
# .github/workflows/test.yml
name: Run Tests
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout 程式碼
uses: actions/checkout@v4
- name: 安裝 Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: 安裝依賴
run: npm ci
- name: 執行測試
run: npm test
push 或建立 PR 時自動執行 Node.js 測試。uses 引用的是 GitHub Marketplace 上的現成 Action。
# .github/workflows/deploy-pages.yml
name: Deploy to GitHub Pages
on:
push:
branches: [ main ]
permissions:
contents: read
pages: write
id-token: write
jobs:
deploy:
runs-on: ubuntu-latest
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Pages
uses: actions/configure-pages@v4
- name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path: '.'
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
這是使用 Actions 部署 GitHub Pages 的官方推薦方式。
| 語法 | 說明 |
|---|---|
name: | workflow 的名稱,會顯示在 GitHub Actions 頁面。 |
on: | 定義觸發條件。可以是事件(push、PR)或定時(cron)。 |
jobs: | 定義一個或多個 job。 |
runs-on: | 指定 runner 的作業系統(ubuntu-latest、macos-latest、windows-latest)。 |
steps: | job 中的步驟列表,依序執行。 |
uses: | 使用現成的 Action(格式:owner/repo@version)。 |
run: | 直接執行 shell 指令。 |
with: | 傳入 Action 需要的參數。 |
permissions: | 設定 workflow 的權限(安全性考量)。 |
當 workflow 需要存取 API 金鑰、密碼等敏感資訊時,絕對不能寫在 YAML 檔案中。GitHub 提供了 Secrets 機制來安全地管理這些資訊。
加密儲存的敏感資訊,設定後只能使用、不能查看原始值。
設定方式:Repo → Settings → Secrets and variables → Actions → New repository secret
# 在 workflow 中使用 Secret
steps:
- name: 部署到伺服器
run: ./deploy.sh
env:
API_KEY: ${{ secrets.MY_API_KEY }}
DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
非敏感的設定值,可以在不同層級設定。
# Workflow 層級(所有 Job 共用)
env:
NODE_ENV: production
jobs:
build:
# Job 層級
env:
BUILD_TARGET: web
steps:
- name: 建置
# Step 層級
env:
DEBUG: false
run: npm run build
*** 遮蔽。但請注意:不要在 echo 中直接輸出 secret,也不要把 secret 寫入檔案後上傳為 artifact。
每次 push 或 PR 自動跑測試,確保程式碼品質。測試不過就不能 merge。
測試通過後自動部署到 GitHub Pages、Vercel、AWS 等平台。
自動執行 ESLint、Prettier 等工具,統一程式碼風格。
根據 tag 自動建立 GitHub Release 並產生 changelog。
自動為新 Issue 加標籤、指派人員、回覆範本訊息。
用 cron 語法定時執行,例如每天自動備份或更新資料。
| 功能 | 說明 | 適用場景 |
|---|---|---|
| GitHub Codespaces | 雲端開發環境,在瀏覽器中直接開啟 VS Code 編輯器,免安裝任何工具。 | 快速開始開發、教學環境、遠端協作。 |
| GitHub Copilot | AI 程式碼助手,在編輯器中即時提供程式碼建議與自動完成。 | 提升程式碼撰寫效率、學習新語言。 |
| GitHub Discussions | Repo 專屬的討論區,像論壇一樣的問答與交流空間。 | 社群互動、Q&A、功能投票。 |
| GitHub Packages | 託管套件(npm、Docker、Maven 等),與 Repo 整合。 | 發布與管理套件、Docker Image。 |
| GitHub Projects | 進階看板工具,支援自訂欄位、自動化規則與多種視圖(表格、看板、時間軸)。 | 專案管理、Sprint 規劃。 |
| Branch Protection Rules | 保護分支的規則:強制 PR 審查、必須通過 CI 測試才能合併。 | 保護 main 分支穩定性。 |
| Dependabot | 自動偵測專案依賴的安全漏洞,並建立 PR 更新到安全版本。 | 依賴管理、安全維護。 |
| 方案 | 每月免費額度 | Storage |
|---|---|---|
| Free | 2,000 分鐘(Linux runner) | 500 MB |
| Pro | 3,000 分鐘 | 1 GB |
| Team | 3,000 分鐘 | 2 GB |
| Enterprise | 50,000 分鐘 | 50 GB |
index.html。.github/workflows/hello.yml。strategy.matrix 的 workflow。.github/workflows/deploy-pages.yml。