2025 iThome鐵人賽
「 Flutter ：30天打造念佛App，跨平台從Mobile到VR，讓極樂世界在眼前實現! 」

Day 8
「 Flutter Git 實戰應用篇—穿越到Coding世界的勇者啊，你骨骼驚奇需要這本秘笈(3) 」

前言

在前兩天的內容，我們已經得到使用Git神裝的秘笈—
「Git GUI」、「Git CLI」兩種Git 操作方法的武功秘笈。

今天我們來進一步認識「GitHub Flow」、「GitHub Actions CI」!

Day8 文章目錄：
一、GitHub Flow
二、GitHub Actions
三、GitHub Actions CI

一、GitHub Flow

GitHub Flow是一種 主幹式開發（trunk-based) 的簡化流程

特點：

1. 僅三種分支類型：main(長期) 、feature(短生命週期)、hotfix (必要時)
2. 從main切出、回main合併：
   開發流程皆由main切出，完成新功能或修復後，Pull Request合併回main。
3. 保持main可隨時上線：main 長期維持可部署狀態，合併完成後通常立即部署；
   完成的 feature、hotfix 分支會刪除。

優點：

• 流程簡單、PR 小、可快速合併與部署，適合持續交付（CD）與需求變動快的專案。

缺點與風險 ：

• Code Review 深度可能不足。
• 多分支並行開發若未及時同步 main，
  可能導致回歸（Regression）：新版本再次出現先前已修復的 Bug。

下圖是流程示意，
右側標示 Regression Risk：feature2 合併時若未同步 main，
可能覆蓋 v1.1.1 的修補，造成回歸。

二、GitHub Actions

GitHub Actions 是 GitHub 內建的自動化平台。

可以在推送（push）、發PR、發佈 Release 等事件時，
幫我們自動執行設定好的工作流程（Workflow）。

1. 常見工作流程：CI / CD

• 持續整合（Continuous Integration, CI）
  • 目標：在合併到 main 前，自動驗證變更是否安全。
  • 流程：每次提交或 PR，自動執行 Lint、單元測試、建置檢查。
  • 好處：及早發現問題，降低 merge 衝突與 回歸（Regression） 風險。
• 持續交付／部署（Continuous Delivery / Deployment, CD）
  • 持續交付：CI 綠燈後，自動打包並準備好可部署產物。
  • 持續部署：更進一步，自動部署到正式環境，達到快速且頻繁上線。

2. Flutter 專案常見用法

• 靜態分析／格式檢查：flutter analyze、dart format --verify，維持一致風格與品質。
• 自動化測試：flutter test（單元／Widget），避免 Regression。
• 建置驗證：確認 Android / iOS / Web 都能成功編譯。
• 自動發佈：合併到 main 後，將測試包上傳至 Firebase App Distribution 或 TestFlight。

3. 提醒

• workflow 檔要放在 .github/workflows/*.yml。
• 在 workflow 設 permissions（如 contents: read），僅給需要的權限。

• 建議將「必須通過的檢查」設為 Required status checks（Branch protection）。

三、GitHub Actions CI

我們來為念佛App專案建立Conventional Commits的GitHub Actions CI，
確保維持乾淨的提交歷史，也利於日後自動產生版本記錄與變更日誌。

1. 專案根目錄建立資料夾與檔案

.github/ 
└── workflows/
    └── <workflow-name>.yml

.github/ 
└── workflows/
    └── conventional-commits-lint.yml

2. 編輯 workflow

• YAML基本結構

name: Workflow 名稱  # 可選，會顯示在 GitHub Actions 介面

on:                # 觸發條件（什麼時候執行）
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
    
permissions:        #權限設置
  contents: read    #只給需要的權限

jobs:              # 定義要執行的工作（可以有多個）
  build:           # job 名稱
    runs-on: ubuntu-latest  # 執行環境：例如 ubuntu-latest, macos-latest, windows-latest

    steps:         # 每個 job 由一系列 steps 組成
      - name: Checkout code
        uses: actions/checkout@v4   # 下載 repo 原始碼

      - name: Run a script
        run: echo "Hello GitHub Actions!"  # 執行指令

name: Conventional Commits Lint

on:
  pull_request:
    types: [opened, synchronize, edited, reopened]

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

permissions:
  contents: read
  pull-requests: read

jobs:
  commitlint:
    name: Lint commit messages
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      
      - name: Run commitlint
        uses: wagoid/commitlint-github-action@v6
        with:
          helpURL: https://www.conventionalcommits.org/zh-hant/v1.0.0/

• 可以參考官方模板

• 可以 Marketplace 搜尋actions

• checkout，幾乎是必備，因為GitHub Action job 開始時還沒有Repo的程式碼。

3. 正確位置才會觸發Actions

Workflow 檔案必須放在 .github/workflows/，副檔名 .yml/.yaml。

4. 確認Actions

5. 驗證

Day8 重點回顧