DevOps on kenji.blog

【Git 指令】rebase 與 merge 的差異與實務上的正確使用時機

Sun, 13 Sep 2026 09:00:00 +0900

1. 前言：為什麼「要用 merge 還是 rebase」是個永遠的課題

Git 是現代軟體開發中不可或缺的版本控制系統。當多位開發者同時修改程式碼庫時，Git 強大的分支模型便能發揮其威力。然而，在團隊開發中，「該使用 merge 還是 rebase」的爭論，是從初學者到老手都經常煩惱的議題之一。

本文將從 Git 的內部結構：DAG（有向無環圖）以及提交（Commit）雜湊（Hash）的數學性質出發，深入探討 git merge 與 git rebase 的機制差異。接著，將配合具體的工作流程，徹底解說在實務上該如何正確區分使用它們。這不僅僅是介紹指令，透過理解 Git 在背後進行了哪些計算，你將不再對衝突（Conflict）感到恐懼，並能建立出乾淨且可追蹤的歷史紀錄。

2. Git 的內部結構：提交雜湊與物件模型

為了理解 Git 是如何整合歷史紀錄的，我們必須先了解 Git 是如何儲存資料的。Git 並不只是儲存檔案修改的差異（Patch），而是儲存特定時間點整個檔案系統的快照（Snapshot）。

2.1 提交雜湊的密碼學性質

Git 的每一個提交，都是透過 SHA-1（Secure Hash Algorithm 1）雜湊函數，根據其內容計算出一組 40 個字元的十六進位數字來唯一識別。提交物件（Commit Object）由以下元素組成：

指向 Tree 物件的指標：該時間點的目錄結構與檔案（Blob）的快照
指向父提交的指標：一個或多個父提交的雜湊值（首次提交沒有父提交，而合併提交則有兩個以上的父提交）
作者資訊（Author）：撰寫程式碼的人與時間
提交者資訊（Committer）：建立與套用提交的人與時間
提交訊息（Commit Message）：說明修改意圖的文字

用數學來表示，對於提交物件 $C$，其雜湊值 $H(C)$ 定義如下：

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

這裡的 $\parallel$ 代表資料的串接。由於雜湊函數的特性，即使只改變了提交訊息中的一個字元，或是父提交不同，都會產生完全不同的雜湊值。也就是說，提交是不可變的（Immutable）。後文將提到 rebase 常被說成是「改寫歷史紀錄」，實際上它是「建立內容相似但雜湊值不同的新提交」。

雜湊空間的大小為 $2^{160}$，利用生日攻擊（Birthday Paradox）的理論，可以近似計算出發生碰撞（Collision，即不同提交擁有相同雜湊值）的機率 $P$（$n$ 為提交數量）：

$$ P(\text{collision}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

這個機率極低，在實務上 Git 的提交雜湊幾乎不可能發生碰撞。

3. 圖論與 DAG：Git 歷史的數學模型

Git 的提交歷史，在圖論中被模型化為「有向無環圖（Directed Acyclic Graph, DAG）」。

3.1 什麼是 DAG（有向無環圖）

在圖 $G = (V, E)$ 中，$V$ 是提交的集合（頂點），$E$ 是表示提交之間父子關係的有向邊集合。在 Git 中，邊的方向是「從子提交指向父提交」。這是因為新的提交會保存指向過去提交的指標。

graph BT
A["Commit A (初始)"]
B["Commit B"]
C["Commit C (主分支)"]
D["Commit D (功能分支)"]
E["Commit E (合併)"]
B --> A
C --> B
D --> B
E --> C
E --> D

DAG 最大的特徵是「不存在循環（Cycle）」。因此，追溯提交歷史的演算法不會陷入無限迴圈，並且能確實到達終點（初始提交）。

3.2 拓撲排序與歷史順序

當我們使用 git log 等指令顯示歷史紀錄時，DAG 會透過拓撲排序（Topological Sort）演算法被排序為一維的列表。對於 DAG 中任意的有向邊 $u \to v$（$u$ 為 $v$ 的子節點），在列表中 $u$ 會被排在 $v$ 的前面。

4. git merge 的機制與種類

整合分支變更最基本的指令就是 git merge。然而，根據目前的狀態，Git 會自動選擇不同的合併策略。

4.1 快轉合併（Fast-Forward, –ff）

如果整合目標（例如：main）分支是整合來源（例如：feature）分支的直接祖先，Git 就會執行「快轉（Fast-Forward）」合併。這是一個不會建立新提交，只是單純將分支指標向前推進的操作。

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

快轉合併能讓歷史紀錄保持一直線，但缺點是會失去「哪些提交是屬於同一個功能開發（feature）」的上下文資訊。

4.2 非快轉合併（Non-Fast-Forward, –no-ff）

如果明確指定 git merge --no-ff，即使在可以快轉合併的情況下，也必定會建立一個新的「合併提交（Merge Commit）」。合併提交是擁有兩個父節點的特殊提交。

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "Main 工作 1"
merge feature type: NORMAL

這種方法的優點是，功能分支的存在與歷史會明確地保留在 DAG 上。當發生問題時，只要執行 git revert -m 1 <合併提交的雜湊>，就可以安全地一次將整個功能取消（Revert）。

4.3 三方合併（3-Way Merge）演算法

當整合目標與整合來源的分支各自擁有獨立的提交時，Git 會執行三方合併。此時，Git 會探索 DAG，並找出兩個分支的「共同祖先（Lowest Common Ancestor, LCA）」。

找出 LCA 的演算法時間複雜度 $T_{\text{LCA}}$，相對於頂點數 $|V|$ 與邊數 $|E|$，可以在線性時間內執行完成：

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

Git 會比較「LCA 的狀態」、「目前分支的狀態」與「對方分支的狀態」這三者，若變更沒有衝突，就會自動產生合併提交。

5. git rebase 的機制與歷史的重建

相較於 git merge 是將歷史「整合」，git rebase 則是將歷史「重建（移花接木）」。

5.1 Rebase 背後的運作方式

將 feature 分支變基到 main 分支（git rebase main）時，內部的運作方式如下：

找出 feature 分支與 main 分支的共同祖先（LCA）。
將從 LCA 到 feature 分支最前端的提交差異，儲存到暫存區域。
將 feature 分支的指標移動到 main 分支的最前端。
將儲存的差異，依序一個個套用（Cherry-Pick）到新的基底（main 的最前端）上，並產生新的提交。

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C (主分支)"]
B --> D["Commit D (舊功能分支)"]
D -.-> E["Commit D' (新功能分支)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

這裡重要的是，透過 rebase 產生的提交 $D'$，因為父提交與原本的提交 $D$ 不同，所以會有完全不同的雜湊值（請參考前面提到的雜湊函數定義 $H(C)$）。

5.2 互動式變基（Interactive Rebase）

使用 git rebase -i（或 --interactive），可以隨心所欲地操作提交歷史。這是用來整理本地端歷史紀錄最強大的工具。

pick：直接採用該提交
reword：只修改提交訊息
edit：暫停以修改提交內容
squash：將此提交與前一個提交融合，並合併兩者的訊息
fixup：與 squash 相同，但會捨棄此提交的訊息
drop：完全刪除該提交

從數學的角度來看，如果一個分支上有 $N$ 個提交，透過 rebase 改變順序所能產生的線性歷史排列組合（排列）$P$ 如下：

$$ P = N! $$

Git 給予了開發者 $N!$ 種自由，使其能夠保持歷史紀錄在合乎邏輯且優美的狀態。

6. Rebase 的黃金法則（The Golden Rule of Rebase）

rebase 雖然非常強大，但存在一個絕對的規則。

「絕對不要對已經公開的歷史紀錄進行 rebase」 (Never rebase public history)

6.1 為什麼不能對公開的歷史紀錄進行 rebase？

Git 是分散式的。你推送到 origin/main 的提交，也會被複製（Clone）到其他開發者的本地端儲存庫中。如果你對已經推送的提交進行 rebase 來改寫歷史，並且使用 git push --force 強制覆蓋，會發生什麼事呢？

其他開發者本地端的 DAG 會與遠端的 DAG 產生根本性的分歧。當其他開發者執行 git pull 時，Git 會試圖強制合併擁有不同歷史的提交群，導致產生大量衝突或重複的提交（內容相同但雜湊不同的提交），讓儲存庫陷入混亂狀態。

Rebase 的鐵則就是**只能對「尚未與任何人共享的本地端分支」**執行。

7. 解決衝突（Conflict）與 git rebase –continue

當多個人修改了同一個檔案的同一個地方時，就會發生衝突。merge 與 rebase 在解決衝突的過程上有所不同。

7.1 Merge 中的衝突解決

在使用 git merge 的情況下，衝突解決只會發生一次。在建立最終的合併提交之前，會一次性修正所有衝突的地方。

7.2 Rebase 中的衝突解決

在使用 git rebase 的情況下，由於是將提交一個一個重新套用，因此每個提交都有可能發生衝突。

在 rebase 過程中若發生衝突，Git 會暫停處理。解決的流程如下：

開啟編輯器或 IDE（例如 VS Code），手動修正衝突標記（<<<<<<<、======、>>>>>>>）。
將修正好的檔案加入索引：
1

git add <修正的檔案>
不建立提交，直接恢復 rebase 處理：
1

git rebase --continue

如果是想要取消 rebase 本身並恢復到原本的狀態，則執行以下指令：

1

git rebase --abort

（※如果不需要解決衝突，想直接略過該提交，則使用 git rebase --skip）

8. 實務上的正確使用時機（工作流程實踐）

那麼，在實際的開發現場中，應該如何區分使用 merge 和 rebase 呢？這裡介紹最標準且安全的做法。

8.1 【情境 1】整理本地端的工作歷史（使用 Rebase）

假設在功能分支開發中，累積了許多細碎的提交（例如「修正拼寫錯誤」、「暫存」等）。在發出發布請求（Pull Request, PR）之前，為了將這些提交整理成有意義的單位，可以使用互動式變基。

1
2
3


# 在 feature 分支的狀態下執行
git rebase -i HEAD~5
# （編輯器會開啟，使用 squash 或 fixup 來讓歷史變得乾淨）

這樣一來，就能建立出讓審查者更容易理解意圖、優美的提交歷史。

8.2 【情境 2】跟上最新的 main 分支（使用 Rebase）

當開發時間拉長，main 分支不斷被合併了其他人的變更，自己的 feature 分支就會變舊。在這種情況下，將 feature 分支 rebase 到最新的 main 上以保持同步。

1
2
3
4
5


# 取得 main 的最新資訊
git fetch origin

# 將 feature 分支重新接到最新的 main 之上
git rebase origin/main

這樣可以讓歷史保持一直線，並防止後續合併時發生衝突。同時也能避免產生多餘的合併提交（“Merge branch ‘main’ into feature”）。

8.3 【情境 3】整合完成的功能（使用 Merge）

當 feature 分支上的開發完成，終於要整合到 main 分支的階段時。這裡要使用 git merge --no-ff（這等同於在 GitHub 等的 Pull Request 中選擇「Create a merge commit」）。

1
2
3


git checkout main
git merge --no-ff feature -m "Merge feature: 實作使用者登入功能"
git push origin main

如此一來，main 分支的 DAG 上就會留下「在這裡合併了一個功能」的歷史節點（合併提交）。日後回顧歷史時，就能以功能為單位輕鬆追蹤程式碼。

9. 結論（總結）

在 Git 的操作中，「全部都用 Merge 解決」或是「全部都用 Rebase 弄成一直線」這類極端的做法，各自都有其優缺點。

實務上的最佳實踐是**「本地端的私人歷史用 rebase 優美地整理，公開的整合歷史用 merge –no-ff 保留上下文」**這種混合式的方法。

本地端（個人的工作空間）：使用 rebase 排除無謂的提交，並跟上最新的主線，維持一直線的歷史。
全域（共享的工作空間）：使用 merge --no-ff 將功能分支的存在作為合併提交記錄在 DAG 上，讓 revert 或追蹤變得更容易。

透過理解 DAG 的結構與雜湊函數機制的數學及架構背景，Git 指令就不再只是單純的死記硬背，而是昇華為「有目的的歷史紀錄設計」。請遵守 rebase 的黃金法則，並根據情況選擇最合適的指令，建立出對整個團隊來說易讀且易於維護的乾淨提交歷史吧。

使用 GitHub Actions 建構 C++ 專案的 CI/CD 管線

Sat, 12 Sep 2026 18:00:00 +0900

使用 GitHub Actions 建構 C++ 專案的 CI/CD 管線：完整指南

在現代軟體開發典範中，持續整合（Continuous Integration: CI）與持續交付/部署（Continuous Delivery/Deployment: CD）是維持敏捷開發流程與高品質軟體不可或缺的要素。在眾多的程式語言中，為 C++ 建構 CI/CD 管線與其他語言（例如 Python、JavaScript、Go 等）相比，伴隨著獨特的困難與複雜性。

本文將極其詳細地解說，如何活用 GitHub Actions，從零開始為 C++ 專案建構一個強健且實用的 CI/CD 管線。我們將涵蓋所有實踐技巧，包括跨平台（Windows、Linux、macOS）的矩陣建置（Matrix Build）、整合使用 CMake 的建置系統、利用 CTest 進行自動化測試、靜態與動態分析的自動化、涵蓋率（Coverage）測量，以及透過 GitHub Releases 自動交付已編譯好的二進位檔案。

1. C++ 專案中 CI/CD 的意義與特有挑戰

在開發 Web 應用程式或使用腳本語言時，大多只需在單一 Docker 容器上進行測試和建置就足夠了。然而，C++ 是原生編譯的語言，強烈依賴執行環境的硬體架構和作業系統。

在為 C++ 專案導入 CI/CD 時，主要會面臨以下挑戰：

平台的多樣性: Windows、Linux、macOS 等不同 OS 會有不同的 API（Windows API、POSIX 等）。在開發者的本地環境（例如 macOS）可以順利運作，但在 Linux 或 Windows 上發生編譯錯誤是家常便飯。
編譯器的差異: Microsoft Visual C++ (MSVC)、GNU Compiler Collection (GCC)、Clang 等主要編譯器，對於 C++ 標準（C++17、C++20、C++23）的實作程度、解釋以及警告的嚴格程度各不相同。
建置時間: 在大型 C++ 專案中，建置花費數十分鐘到數小時的情況並不罕見。在 CI 環境有限的運算資源下，需要有快取策略和並列處理來有效率地進行建置。
相依性管理: C++ 並不存在像 npm 或 pip 那樣絕對標準的套件管理器。需要使用 vcpkg、Conan 或 CMake 的 FetchContent 等，在 CI 環境上每次都正確地解析函式庫。
記憶體管理與未定義行為: 由於伴隨著指標操作和手動記憶體管理，不僅是單純的邏輯測試，還必須將記憶體流失和未定義行為（Undefined Behavior）的偵測自動化。

為了解決這些挑戰，能夠依需求配置各種 OS 虛擬機器，並將複雜的工作流程以程式碼定義（Configuration as Code）的 GitHub Actions 便成為了最佳解決方案。

2. CI/CD 管線的架構概觀

讓我們將接下來要建構的 CI/CD 管線全貌視覺化。以下的 Mermaid 循序圖展示了從程式碼 Push 到發布的工作流程。

sequenceDiagram
participant Dev as "開發者"
participant Repo as "GitHub 儲存庫"
participant Action as "GitHub Actions CI/CD"
participant Rel as "GitHub Releases"
Dev->>Repo: "推送分支 / 建立 PR"
Repo->>Action: "觸發 CI 工作流程"
activate Action
Action->>Action: "Lint 與靜態分析 (Clang-Tidy)"
rect rgb(200, 220, 240)
note right of Action: "跨平台矩陣建置"
Action->>Action: "在 Ubuntu 上建置 (GCC/Clang)"
Action->>Action: "在 Windows 上建置 (MSVC)"
Action->>Action: "在 macOS 上建置 (Apple Clang)"
end
Action->>Action: "執行 CTest (搭配 ASAN/UBSAN)"
Action->>Action: "產生涵蓋率報告"
alt "如果是推送標籤 (例如 v1.0.0)"
Action->>Action: "使用 CPack 打包二進位檔案"
Action->>Rel: "上傳 ZIP/Tarball 至 Release"
end
deactivate Action
Repo-->>Dev: "回報 CI 狀態 (通過/失敗)"

在這個架構中，在 Pull Request 階段會提供快速的回饋（靜態分析與建置、測試），並在加上版本標籤的時間點進行產出物的打包與發布。

3. 現代化 CMake 的專案設定

優良的 CI 管線的基礎在於強健的建置系統。我們使用 C++ 的業界標準 CMake。在此，我們採用被稱為「現代化 CMake」的導向目標方法。

假設專案的目錄結構如下：

1
2
3
4
5
6
7
8
9


my_cpp_project/
├── CMakeLists.txt
├── src/
│ ├── main.cpp
│ ├── calculator.cpp
│ └── calculator.h
└── tests/
 ├── CMakeLists.txt
 └── test_calculator.cpp

根目錄的 CMakeLists.txt 設定範例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


cmake_minimum_required(VERSION 3.20)
project(MyCppProject VERSION 1.0.0 LANGUAGES CXX)

# C++ 標準設定
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF) # 停用編譯器專屬的擴充以提高可移植性

# 嚴格化編譯器警告
function(set_project_warnings target_name)
 if(MSVC)
 target_compile_options(${target_name} PRIVATE /W4 /WX)
 else()
 target_compile_options(${target_name} PRIVATE -Wall -Wextra -Wpedantic -Werror)
 endif()
endfunction()

# 建立函式庫目標
add_library(CalculatorLib src/calculator.cpp)
target_include_directories(CalculatorLib PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/src)
set_project_warnings(CalculatorLib)

# 建立執行檔目標
add_executable(MyApplication src/main.cpp)
target_link_libraries(MyApplication PRIVATE CalculatorLib)
set_project_warnings(MyApplication)

# 啟用測試
enable_testing()
add_subdirectory(tests)

# 定義安裝規則 (供 CPack 使用)
include(GNUInstallDirs)
install(TARGETS MyApplication CalculatorLib
 RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
 LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
 ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
)

# 透過 CPack 的打包設定
set(CPACK_PROJECT_NAME ${PROJECT_NAME})
set(CPACK_PROJECT_VERSION ${PROJECT_VERSION})
set(CPACK_GENERATOR "ZIP;TGZ")
if(WIN32)
 set(CPACK_GENERATOR "ZIP")
endif()
include(CPack)

重點：

CMAKE_CXX_EXTENSIONS OFF: 防止依賴 GNU 擴充等非標準功能，確保跨平台相容性。
嚴格化警告 (-Werror / /WX): 在 CI 環境中將編譯器警告視為錯誤，強制保持較高的程式碼品質。
GNUInstallDirs: 自動解析各 OS 專屬的標準安裝路徑（如 /usr/local/bin 或 C:\Program Files）。

4. GitHub Actions 基礎與矩陣策略

GitHub Actions 是透過 .github/workflows/ 目錄內的 YAML 檔案來配置。在 C++ 專案中最強大的功能是「矩陣策略（Matrix Strategy）」。這使得我們能動態產生 OS 與編譯器的組合，並並列執行。

graph TD
A["觸發工作流程"] --> B["矩陣作業評估"]
B --> C["Ubuntu 22.04 (GCC 12)"]
B --> D["Ubuntu 22.04 (Clang 15)"]
B --> E["Windows Server 2022 (MSVC)"]
B --> F["macOS 14 (Apple Clang)"]

以下展示作為矩陣建置基礎的 YAML 作業定義。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


jobs:
 build:
 name: "Build & Test [${{ matrix.os }} - ${{ matrix.compiler }}]"
 runs-on: ${{ matrix.os }}
 strategy:
 fail-fast: false # 即便 1 個作業失敗，也繼續進行其他 OS 的建置
 matrix:
 include:
 - os: ubuntu-latest
 compiler: gcc
 c_compiler: gcc
 cpp_compiler: g++
 - os: ubuntu-latest
 compiler: clang
 c_compiler: clang
 cpp_compiler: clang++
 - os: windows-latest
 compiler: msvc
 c_compiler: cl
 cpp_compiler: cl
 - os: macos-latest
 compiler: apple-clang
 c_compiler: clang
 cpp_compiler: clang++

fail-fast: false 非常重要。舉例來說，如果誤用了 Linux 特有的 API，Ubuntu 的建置會失敗，但我們同時也會想確認 Windows 的建置是否成功。

5. 運用阿姆達爾定律 (Amdahl’s Law) 最佳化建置成本與並列處理

雲端環境的 CI/CD 是一場與時間的賽跑，建置時間直接關乎開發者的等待時間與營運成本。在這裡，關於建置時間的最佳化，我們試著使用電腦科學中的「阿姆達爾定律 (Amdahl’s Law)」來進行數學上的探討。

阿姆達爾定律指出，若程式中可並列化部分的比例為 $P$，則在使用 $N$ 個處理器時，理論上的最大加速比 $S(N)$ 定義如下：

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

在 C++ 的建置過程中，原始碼的各個翻譯單元（Translation Unit: .cpp 檔案）的編譯是完全獨立且可並列化的。另一方面，CMake 的組態設定以及最終二進位檔案的連結階段則基本上是序列執行（無法並列化）。

假設專案整體的建置時間中，有 80% 是編譯階段（$P = 0.8$），20% 是序列階段（$1 - P = 0.2$）。 GitHub Actions 的標準執行器（Linux）提供 2 個核心（執行緒）。因此當 $N = 2$ 時：

$$ S(2) = \frac{1}{0.2 + \frac{0.8}{2}} = \frac{1}{0.2 + 0.4} = \frac{1}{0.6} \approx 1.67 $$

僅使用 2 核心，就能獲得大約 1.67 倍的速度提升。為了實現這一點，在 CMake 的建置指令中指定 --parallel 參數是不可或缺的。

1
2


 - name: "Build Project"
 run: cmake --build build --config Release --parallel 2

此外，也必須考慮成本計算。GitHub Actions 的使用成本 $C_{total}$ 是作業執行時間 $T_i$ 與執行器單價 $R_i$ 乘積的總和。

$$ C_{total} = \sum_{i=1}^{M} \left( T_i \times R_i \right) $$

縮短建置時間不僅能加速回饋迴圈，還能直接降低專案的營運成本（特別是在私人儲存庫的情況下）。若追求進一步的加速，導入 ccache 來快取編譯結果將是有效的手法。

6. 自動化測試與 Sanitizers 的整合

在 C++ 中為了防範 Bug 於未然，除了單元測試之外，強烈建議導入在執行期偵測記憶體流失與未定義行為的「Sanitizer」。我們將使用由 Google 開發的 AddressSanitizer (ASAN) 與 UndefinedBehaviorSanitizer (UBSAN)。

在 CMake 中新增啟用 Sanitizer 的選項。

1
2
3
4
5


option(ENABLE_SANITIZERS "Enable ASAN and UBSAN" OFF)
if(ENABLE_SANITIZERS AND CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
 add_compile_options(-fsanitize=address,undefined -fno-omit-frame-pointer)
 add_link_options(-fsanitize=address,undefined)
endif()

在 CI 管線的 Ubuntu 作業中啟用這個選項來執行測試。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 - name: "Configure CMake"
 env:
 CC: ${{ matrix.c_compiler }}
 CXX: ${{ matrix.cpp_compiler }}
 run: >
 cmake -B build
 -DCMAKE_BUILD_TYPE=Release
 -DENABLE_SANITIZERS=${{ matrix.os == 'ubuntu-latest' && 'ON' || 'OFF' }}

 - name: "Run CTest"
 working-directory: build
 env:
 ASAN_OPTIONS: "detect_leaks=1:symbolize=1"
 UBSAN_OPTIONS: "print_stacktrace=1"
 run: ctest --build-config Release --output-on-failure --parallel 2

測試的執行使用 ctest 指令。藉由指定 --output-on-failure，只會在 CI 輸出中顯示失敗測試的詳細日誌，以防止日誌過於龐大。

7. 測量涵蓋率（程式碼涵蓋率）

將測試涵蓋了多少程式碼視覺化，對於品質保證十分重要。我們將利用 Linux 環境 (GCC)，並使用 gcov 及 lcov 來測量涵蓋率。

首先，在 CMake 中設定涵蓋率測量用的編譯旗標。

1
2
3
4
5


option(ENABLE_COVERAGE "Enable coverage reporting" OFF)
if(ENABLE_COVERAGE AND CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
 add_compile_options(--coverage -O0 -g)
 add_link_options(--coverage)
endif()

在 GitHub Actions 中定義一個獨立的作業用於涵蓋率測量。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


 coverage:
 name: "Test Coverage Analysis"
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - name: "Install lcov"
 run: sudo apt-get update && sudo apt-get install -y lcov

 - name: "Configure CMake for Coverage"
 run: cmake -B build -DCMAKE_BUILD_TYPE=Debug -DENABLE_COVERAGE=ON

 - name: "Build & Test"
 run: |
 cmake --build build --parallel 2
 cd build && ctest --output-on-failure

 - name: "Generate lcov Report"
 working-directory: build
 run: |
 lcov --capture --directory . --output-file coverage.info
 lcov --remove coverage.info '/usr/*' '*_deps/*' '*tests/*' --output-file coverage.info
 
 - name: "Upload Coverage to Codecov"
 uses: codecov/codecov-action@v3
 with:
 files: build/coverage.info

使用 lcov --remove 指令，將系統標頭檔、第三方函式庫以及測試程式碼本身從涵蓋率的測量對象中排除。這樣一來，就能獲得專案專屬原始碼的純粹涵蓋率。

8. 透過 GitHub Releases 自動交付二進位檔案 (CD)

接著建構 CI/CD 中 “CD” 的部分。當開發者在 Git 中加上版本標籤（例: v1.2.0）並推送時，會自動為各 OS 編譯可執行檔，並打包成 ZIP 或 Tarball，然後上傳至 GitHub Releases。

這個步驟將使用隨附於 CMake 的打包工具 CPack。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


 - name: "Package Application (CPack)"
 if: startsWith(github.ref, 'refs/tags/v')
 working-directory: build
 run: cpack -C Release -V

 - name: "Upload Release Assets"
 if: startsWith(github.ref, 'refs/tags/v')
 uses: softprops/action-gh-release@v1
 with:
 files: |
 build/*.tar.gz
 build/*.zip
 build/*.sh
 build/*.exe
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

透過這個設定，只要執行 git tag v1.0.0 與 git push origin v1.0.0，就能在無須手動介入的情況下，自動將供 Windows 使用者的 ZIP 檔，以及供 Linux/macOS 使用者的 Tarball 公開到發布頁面。這對於向使用者傳遞軟體而言是極為強大的功能。

9. 完整的 Workflow YAML 檔案

以下展示整合了前面解說的所有要素，強健且實用的 .github/workflows/main.yml 完整程式碼。

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107


name: "C++ CI/CD Pipeline"

on:
 push:
 branches: [ "main", "develop" ]
 tags: [ "v*.*.*" ]
 pull_request:
 branches: [ "main" ]

env:
 BUILD_TYPE: Release

jobs:
 build-and-test:
 name: "Build [${{ matrix.os }} | ${{ matrix.compiler }}]"
 runs-on: ${{ matrix.os }}
 strategy:
 fail-fast: false
 matrix:
 include:
 - os: ubuntu-latest
 compiler: gcc
 c_compiler: gcc
 cpp_compiler: g++
 - os: ubuntu-latest
 compiler: clang
 c_compiler: clang
 cpp_compiler: clang++
 - os: windows-latest
 compiler: msvc
 c_compiler: cl
 cpp_compiler: cl
 - os: macos-latest
 compiler: apple-clang
 c_compiler: clang
 cpp_compiler: clang++

 steps:
 - name: "Checkout Repository"
 uses: actions/checkout@v4

 - name: "Configure CMake"
 env:
 CC: ${{ matrix.c_compiler }}
 CXX: ${{ matrix.cpp_compiler }}
 run: >
 cmake -B build
 -DCMAKE_BUILD_TYPE=${{ env.BUILD_TYPE }}
 -DENABLE_SANITIZERS=${{ matrix.os == 'ubuntu-latest' && 'ON' || 'OFF' }}

 - name: "Build Project"
 run: cmake --build build --config ${{ env.BUILD_TYPE }} --parallel 2

 - name: "Run Unit Tests (CTest)"
 working-directory: build
 env:
 ASAN_OPTIONS: "detect_leaks=1:symbolize=1"
 UBSAN_OPTIONS: "print_stacktrace=1"
 run: ctest --build-config ${{ env.BUILD_TYPE }} --output-on-failure --parallel 2

 - name: "Package with CPack"
 if: startsWith(github.ref, 'refs/tags/v')
 working-directory: build
 run: cpack -C ${{ env.BUILD_TYPE }}

 - name: "Create GitHub Release and Upload Assets"
 if: startsWith(github.ref, 'refs/tags/v')
 uses: softprops/action-gh-release@v1
 with:
 files: |
 build/*.tar.gz
 build/*.zip
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

 coverage:
 name: "Code Coverage Analysis"
 runs-on: ubuntu-latest
 if: github.event_name == 'pull_request' || github.ref == 'refs/heads/main'
 steps:
 - name: "Checkout Repository"
 uses: actions/checkout@v4

 - name: "Install lcov"
 run: sudo apt-get update && sudo apt-get install -y lcov

 - name: "Configure CMake for Coverage"
 run: cmake -B build -DCMAKE_BUILD_TYPE=Debug -DENABLE_COVERAGE=ON

 - name: "Build Project"
 run: cmake --build build --parallel 2

 - name: "Run Tests"
 working-directory: build
 run: ctest --output-on-failure

 - name: "Generate lcov Report"
 working-directory: build
 run: |
 lcov --capture --directory . --output-file coverage.info
 lcov --remove coverage.info '/usr/*' '*_deps/*' '*tests/*' --output-file coverage.info
 
 - name: "Upload Coverage to Codecov"
 uses: codecov/codecov-action@v3
 with:
 files: build/coverage.info
 fail_ci_if_error: false

10. 邁向更進階的 CI/CD（靜態分析與格式化）

在此省略詳細解說，但在實際運用上，建議將進階的品質保證工具整合進管線中。

強制 Clang-Format: 為了減輕程式碼審查的負擔，將透過 clang-format 的程式碼風格檢查整合進 CI，當違反格式規則時便讓管線失敗。
靜態分析 (Clang-Tidy): 為了偵測單靠編譯器警告無法防範的潛在 Bug，或是無效率的程式碼（如不必要的複製等），將 clang-tidy 整合至 CMake 並在 CI 上執行。
活用 vcpkg / Conan 快取: 若使用大量第三方函式庫，建置相依套件將會花費大量時間。利用 GitHub Actions 的 actions/cache 來保留 vcpkg 的安裝目錄或 Conan 的快取，能戲劇性地縮減建置時間。

結論

在 C++ 專案中建構 CI/CD 管線，由於平台相依性及建置工具的複雜度，乍看之下門檻似乎很高。然而，只要正確地結合 GitHub Actions、現代化 CMake 以及 CTest/CPack 生態系，就能獲得極其強大且自動化的開發流程。

本文所解說的：運用矩陣策略進行跨平台驗證、運用 Sanitizer 偵測執行期 Bug、測量涵蓋率，以及自動部署至 GitHub Releases 等，都是在商業級別的開源專案中被廣泛採用的最佳實踐。

自動化的 CI/CD 管線，能將開發者花在「找 Bug」與「手動建置・發布作業」的時間最小化，並成為讓開發者專注於本質上具創造力的程式設計活動的最強武器。請務必在您的 C++ 專案中也導入這套做法，實現敏捷且令人安心的開發生活。

如何在 Cloudflare Pages 或 GitHub Pages 上免費且極速地部署 Hugo 部落格

Sat, 12 Sep 2026 12:00:00 +0900

在營運網站或部落格時，載入速度（效能）、營運成本以及安全性是極為重要的因素。過去，像 WordPress 這樣的動態 CMS（內容管理系統）與虛擬主機的組合是主流，但現在被稱為「Jamstack」的架構正受到極大關注。其中，將以 Go 語言編寫的超高速靜態網站產生器（SSG）「Hugo」與 Cloudflare Pages 或 GitHub Pages 等現代代管服務結合，即可建構出完全免費且極速的部落格環境。

本文將從技術觀點進行非常深入的探討，說明如何將使用 Hugo 產生的靜態網站在 Cloudflare Pages 或 GitHub Pages 上發布的具體步驟、各平台架構的差異、使用 GitHub Actions 建構 CI/CD（持續整合／持續部署）、DNS 的最佳化、快取策略，以及如何導入兼顧隱私的流量分析工具。

1. 靜態網站產生器（SSG）與 Jamstack 基礎

1.1 為什麼選擇靜態網站？

傳統的動態 CMS（例如：WordPress）在每次收到使用者請求時，都會向資料庫（如 MySQL）發出查詢，並在伺服器端（如 PHP）動態產生 HTML 後回傳。這種方式雖然靈活性高，但對流量激增（所謂的爆紅或 DDoS 攻擊）的承受力較低，往往需要將快取伺服器（如 Redis 或 Varnish）放置在前端，導致基礎設施架構變得複雜。

另一方面，採用 Jamstack（JavaScript, APIs, and Markup）架構的靜態網站產生器（SSG），會事先（在建置時）產生所有的 HTML 檔案、CSS 和 JavaScript。對於使用者的請求，網頁伺服器（或 CDN）只需直接回傳已產生的靜態檔案，因此能實現壓倒性的高速與堅固的安全性。

1.2 Hugo 的優勢

SSG 有 Next.js、Gatsby、Jekyll、Astro 等多種選擇，但 Hugo 最大的特色在於其建置速度。受惠於 Go 語言的並行處理，即使是擁有數千至數萬個頁面的網站，也只需短短幾秒鐘即可完成建置。這大幅減少了 CI/CD 流程中的等待時間，直接提升了開發者體驗（DX: Developer Experience）。

2. 代管服務的架構比較

將 Hugo 產生的靜態檔案代管在哪裡是下一個課題。具代表性的選擇包括 Cloudflare Pages、GitHub Pages 以及 Netlify，但它們背後的網路架構各不相同。

2.1 CDN 與邊緣運算

這些平台全部都利用全球分散的 CDN（內容傳遞網路）來傳遞內容。然而，不僅僅是靜態檔案的快取，是否能透過「邊緣運算」在最靠近使用者的 PoP（節點）執行請求的路由或標頭改寫，成為了它們的差異化因素。

graph TD
A["使用者 (東京)"] -->|低延遲| B["邊緣節點 (NRT)"]
C["使用者 (紐約)"] -->|低延遲| D["邊緣節點 (EWR)"]
E["使用者 (倫敦)"] -->|低延遲| F["邊緣節點 (LHR)"]
B --> G["原始儲存 / 物件儲存"]
D --> G
F --> G

2.2 GitHub Pages

GitHub Pages 是能直接從 GitHub 儲存庫發布 HTML、CSS 和 JavaScript 檔案的服務。其背後使用了 Fastly 等 CDN，能發揮出色的效能。不過，在自訂標頭（例如：設定 Cache-Control 或安全性標頭）方面有其限制，且重新導向（Redirect）的設定需要依賴 HTML 的 meta refresh 或 Jekyll 的外掛程式，作為純粹基礎設施的功能稍微受限。

2.3 Cloudflare Pages

Cloudflare Pages 是一個建立在 Cloudflare 引以為傲的全球最大規模 Anycast 網路（部署於 275 個以上城市）之上的靜態網站代管服務。支援 HTTP/3（QUIC）標準、圖片最佳化以及邊緣函式（Cloudflare Workers）的整合，可進行壓倒性的效能調校。此外，它沒有頻寬計費，無論流量如何激增都能免費營運，這是其一大優勢。

2.4 Netlify

Netlify 是 Jamstack 的先驅，提供整合表單功能、驗證（Identity）、無伺服器函式等 All-in-One 的開發者體驗。然而，一旦超過免費額度的頻寬（每月 100GB），將會產生高昂的按量計費，因此在大量使用圖片或影片的部落格中需要注意成本控管。

3. 效能與延遲的理論計算（使用 LaTeX 的數學模型）

在評估網站效能時，減少延遲（Latency）是最重要的指標。讓我們來建立一個模型，看看使用 CDN（邊緣節點）相較於直接存取原始伺服器，能減少多少延遲。

將使用者請求命中快取的機率設為「快取命中率（Cache Hit Ratio）」，並以 $C$ 表示。$0 \le C \le 1$。將到達原始伺服器的延遲設為 $L_{origin}$，到達最近邊緣節點的延遲設為 $L_{edge}$。

新的平均延遲 $L_{new}$ 將以下列的期望值來計算：

$$ L_{new} = C \times L_{edge} + (1 - C) \times (L_{edge} + L_{origin}) $$

將此公式簡化後如下：

$$ L_{new} = L_{edge} + (1 - C) \times L_{origin} $$

例如，當東京的使用者存取位於美國東岸（紐約）的原始伺服器時，若考慮光纖的物理距離與路由器的處理延遲，$L_{origin}$ 大約是 200 ms。另一方面，如果使用像 Cloudflare 這樣的 CDN，因為可以連線到東京的邊緣節點，$L_{edge}$ 將縮短至約 10 ms。

假設快取命中率 $C = 0.95$（95%），

$$ L_{new} = 10 + (1 - 0.95) \times 200 = 10 + 0.05 \times 200 = 10 + 10 = 20 \text{ ms} $$

像這樣，透過導入 CDN，可以將平均延遲從 210 ms 戲劇性地（約 90%）減少至 20 ms。

4. 使用 GitHub Actions 建構 CI/CD 流程

為了將 Hugo 部落格的更新流程自動化，我們將使用 GitHub Actions 建構 CI/CD 流程。如此一來，只需在本地端撰寫 Markdown 文章並執行 git push，就會自動進行建置，並部署到 Cloudflare Pages 或 GitHub Pages 上。

以下循序圖顯示了從推送文章到傳遞給使用者的整體流程。

sequenceDiagram
participant U as "使用者 (作者)"
participant G as "GitHub 儲存庫"
participant A as "GitHub Actions"
participant C as "Cloudflare Pages"
participant V as "訪客"
U->>G: "git push origin main"
G->>A: "觸發 Push 事件"
A->>A: "簽出與設定 Hugo"
A->>A: "hugo --minify (建置)"
A->>C: "部署到 Cloudflare Pages (直接上傳)"
C-->>A: "部署 URL (成功)"
V->>C: "請求網頁"
C-->>V: "回傳快取 HTML (邊緣)"

4.1 針對 Cloudflare Pages 的部署設定（Direct Upload）

Cloudflare Pages 有兩種方式：一種是連結 GitHub 儲存庫並在 Cloudflare 的基礎設施上建置，另一種是將透過 GitHub Actions 建置好的靜態檔案「直接上傳（Direct Upload）」。如果您想要更嚴謹地進行 Hugo 的版本控制，並與其他作業（測試或圖片最佳化）連動，建議採用在 GitHub Actions 上建置並 Direct Upload 的方式。

以下是部署到 Cloudflare Pages 的 .github/workflows/deploy.yml 實務範例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


name: "Deploy Hugo site to Cloudflare Pages"

on:
 push:
 branches:
 - "main"
 workflow_dispatch:

jobs:
 build-and-deploy:
 runs-on: "ubuntu-latest"
 steps:
 - name: "Checkout repository"
 uses: "actions/checkout@v4"
 with:
 submodules: "recursive"
 fetch-depth: 0

 - name: "Setup Hugo"
 uses: "peaceiris/actions-hugo@v3"
 with:
 hugo-version: "0.125.0"
 extended: true

 - name: "Build Hugo Site"
 run: "hugo --minify --gc"
 env:
 HUGO_ENVIRONMENT: "production"

 - name: "Deploy to Cloudflare Pages"
 uses: "cloudflare/pages-action@v1"
 with:
 apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
 accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
 projectName: "your-project-name"
 directory: "public"
 gitHubToken: ${{ secrets.GITHUB_TOKEN }}
 branch: "main"

在這個流程中，透過 --minify 參數將 HTML/CSS/JS 最小化，並透過 --gc 刪除不必要的檔案。這些都是效能最佳化的基礎。

5. 深入 DNS 設定：自訂網域與 CNAME / ALIAS 紀錄

當使用自訂網域（例如：kenji.blog）時，適當的 DNS（網域名稱系統）設定是不可或缺的。

5.1 CNAME 紀錄的限制與 Zone Apex

通常，將子網域（例如：www.kenji.blog）指向外部服務時，會使用 CNAME 紀錄。然而，根據 DNS 規範（RFC 1034），根網域（Zone Apex，也稱為裸網域，例如：kenji.blog）無法設定 CNAME 紀錄。這是因為 Zone Apex 必須存在 SOA（Start of Authority）紀錄、NS（Name Server）紀錄或 MX（Mail Exchange）紀錄，而 CNAME 有無法與其他資源紀錄共存的規則。

5.2 解決方案：ALIAS / ANAME / CNAME Flattening

為了解決這個問題，現代的 DNS 服務商提供了獨家的擴充功能。

ALIAS / ANAME 紀錄：在 DNS 伺服器端動態進行名稱解析，並將最終的 A 紀錄（IP 位址）回傳給客戶端。Amazon Route 53 等支援此功能。
CNAME Flattening：這是 Cloudflare 提供的功能。它讓您可以像在 Zone Apex 上設定 CNAME 一樣，而 Cloudflare 的權威 DNS 伺服器會自動解析並將 IP 位址群（A 紀錄及 AAAA 紀錄）透明地回傳給客戶端。

在使用 Cloudflare Pages 時，將網域的名稱伺服器委派給 Cloudflare，並活用這個「CNAME Flattening」是最無縫且高效能的架構。

6. 快取策略與 HTTP 標頭控制

在加速靜態網站方面，另一個關鍵在於「快取策略」。在 Cloudflare Pages 中，可以利用產生的檔案（_headers 檔案）來詳細控制 HTTP 回應標頭。

6.1 邊緣快取 vs 瀏覽器快取

快取大致分為在 CDN 端保留的「邊緣快取（Edge Cache）」以及儲存在使用者瀏覽器中的「瀏覽器快取（Browser Cache）」兩種。

靜態檔案（圖片、CSS、JS 等檔名中包含雜湊值的檔案）理想情況下是讓瀏覽器長時間快取。另一方面，為了能立即反映 HTML 檔案的更新，通常會將瀏覽器快取縮短（或停用），並交由邊緣快取來處理，這是一般的架構。

Cloudflare Pages 中的 _headers 設定範例：

1
2
3
4
5
6
7
8
9


# HTML 檔案不進行瀏覽器快取，每次都重新驗證
/*.html
 Cache-Control: public, max-age=0, must-revalidate

# 資源檔案（CSS/JS/圖片）讓瀏覽器快取 1 年
/assets/*
 Cache-Control: public, max-age=31536000, immutable
/img/*
 Cache-Control: public, max-age=31536000, immutable

6.2 減少頻寬成本的計算公式

透過設定適當的快取標頭，可以大幅減少伺服器（邊緣節點）的資料傳輸量。每月的頻寬成本 $Cost$ 可由各資源的傳輸量 $B_i$、快取命中率 $C_i$ 以及頻寬單價 $R$ 以下列模型表示：

$$ Cost = \sum_{i=1}^{n} \left( B_i \times (1 - C_i) \times R \right) $$

由於 Cloudflare 的下行傳輸量是免費的（$R = 0$），因此直接的資金成本將為 $0$。但是，若同時使用 GitHub Pages 等其他基礎設施，或是以 AWS S3 等作為後端時，將此快取命中率 $C_i$ 最大化，將成為減少基礎設施成本的關鍵。

7. 兼顧隱私與效能的流量分析

在營運部落格時，為了了解有多少使用者造訪，流量分析（Web Analytics）是不可或缺的。長久以來，Google Analytics（GA4）一直是業界標準，但隨著近年來隱私保護的趨勢（GDPR、CCPA）以及第三方 Cookie 的淘汰，情況正在發生變化。

7.1 對網頁效能的影響

如果導入 Google Analytics（具體來說是 gtag.js 或 Google Tag Manager），將會產生大量外部腳本的載入與執行，對效能（尤其是 TTFB 和主執行緒的阻塞時間）產生不良影響。

讓我們將網站的載入時間分解如下：

pie title "典型的網站載入時間分佈"
"TTFB (首位元組時間)" : 15
"內容下載 (HTML/CSS)" : 20
"DOM 解析與渲染" : 45
"流量分析與第三方 JS" : 20

第三方 JS 分析工具佔據整體載入時間約 20% 到 30% 也是很常見的情況。

7.2 導入 Cloudflare Web Analytics

因此，像 Cloudflare Web Analytics 或 Plausible Analytics 這種不使用 Cookie（Cookieless）且隱私優先的流量分析工具正受到關注。

Cloudflare Web Analytics 只要嵌入非常輕量的 JavaScript 程式碼片段即可運作，且不會發行 Cookie，因此不需要設置繁瑣的 Cookie 同意橫幅（Cookie Consent Banner）。

在 Hugo 中的實作也非常簡單。只需將提供的程式碼片段加入 layouts/partials/head.html 或 layouts/partials/analytics.html 中即可。

1
2
3
4
5


{{ if eq hugo.Environment "production" }}
<!-- Cloudflare Web Analytics -->
<script defer src='https://static.cloudflareinsights.com/beacon.min.js' data-cf-beacon='{"token": "YOUR_CLOUDFLARE_BEACON_TOKEN"}'></script>
<!-- End Cloudflare Web Analytics -->
{{ end }}

透過加上 defer 屬性，可以在不阻塞 HTML 解析的情況下非同步載入腳本，並在 DOM 建構完成後執行。這樣可以將對初始顯示速度（LCP: Largest Contentful Paint 和 FCP: First Contentful Paint）的影響降至最低。

8. 總結與最佳實務

在使用 Hugo 營運靜態網站時，採用 Cloudflare Pages 或 GitHub Pages 等現代代管平台，在成本效益、載入速度以及安全性等各方面都具有壓倒性的優勢。

極速的建置：善用 Hugo 的高速特性，將 CI/CD 流程（GitHub Actions）的執行時間最小化。
在邊緣節點傳遞：利用 Cloudflare 的邊緣網路，以毫秒級的延遲將內容傳遞給全球使用者。
適當的 DNS 架構：活用 CNAME Flattening 安全且高速地營運 Zone Apex（自訂網域）。
快取策略最佳化：使用 _headers，針對不同資源類型適當地分離瀏覽器快取與邊緣快取。
輕量級的分析工具：導入兼顧隱私且不損害效能的 Cloudflare Web Analytics 等工具。

透過結合這些技術，可以免費建構出能夠承受每月數百萬 PV 等級大規模流量，且具備高可擴充性與堅固性的部落格系統。正在考慮建立技術部落格、企業網站或作品集網站的人，請務必嘗試這個 Jamstack + Hugo + Cloudflare Pages 的組合。