Vibe Coder
版本號怎麼升?語意化版本與 CHANGELOG 入門
語意化版本號的格式是 MAJOR.MINOR.PATCH:修 bug 升 PATCH、加新功能且向後相容升 MINOR、有破壞性改動升 MAJOR。搭配 CHANGELOG 記錄每個版本改了什麼,再用 git tag 標記發布點,之後出問題一個指令就能回到上一個穩定版本。
版本號怎麼升?語意化版本與 CHANGELOG 入門
三個月後你不會記得哪個版本加了什麼功能,除非有人幫你記。版本號和 CHANGELOG 就是那個記憶外掛:版本號讓你知道自己改了什麼,CHANGELOG 讓客戶和使用者也知道。這篇帶你搞懂語意化版本怎麼升、CHANGELOG 怎麼寫,以及完整的 Git Tag 發布流程。
你將學到什麼
MAJOR.MINOR.PATCH
三段式版本號各自代表什麼改動,一張表看懂該升哪一段。
什麼時候升哪個號碼
從修 bug 到改欄位名稱,六種常見情境的對照答案。
CHANGELOG 的格式
Keep a Changelog 風格範本,Added、Fixed 分類一目瞭然。
Git Tag 發布流程
從確認測試通過到 push 帶 tag,六個步驟走一遍。
語意化版本:MAJOR.MINOR.PATCH
| 部分 | 什麼時候升 | 例子 |
|---|---|---|
| PATCH(修補) | 向後相容的 bug 修復 | 1.0.0 → 1.0.1 |
| MINOR(次要) | 向後相容的新功能 | 1.0.0 → 1.1.0 |
| MAJOR(主要) | 破壞向後相容的變更 | 1.0.0 → 2.0.0 |
0.x.x 的特殊規則在 1.0.0 之前,所有版本都是 0.x.x,代表 API 可能隨時改變,沒有向後相容承諾。天氣小工具上線前可以用 0.1.0 開始,第一個穩定版本才升到 1.0.0。
什麼時候升版本號
| 發生什麼事 | 升哪個 | 例子 |
|---|---|---|
| 修了一個 bug(不改 API) | PATCH | 1.2.3 → 1.2.4 |
| 加了一個新的 API 端點 | MINOR | 1.2.3 → 1.3.0 |
| 把 /weather 改成 /api/weather | MAJOR(破壞現有使用者) | 1.2.3 → 2.0.0 |
| 改了一個 API 的回傳欄位名稱 | MAJOR(舊的程式碼會壞) | 1.2.3 → 2.0.0 |
| 改善效能但行為不變 | PATCH | 1.2.3 → 1.2.4 |
| 加了選填的 query parameter | MINOR(向後相容) | 1.2.3 → 1.3.0 |
CHANGELOG 的格式
# Changelog
## [1.1.0] - 2026-06-28
### Added
- 加入查詢歷史記錄功能(GET /api/history)
- 使用者可以刪除自己的查詢記錄
### Fixed
- 修正城市名稱大小寫不一致導致快取失效的問題
## [1.0.0] - 2026-06-01
### Added
- 天氣查詢功能(GET /weather/{city})
- 使用者帳號系統(JWT 認證)
Git Tag 發布流程
# 1. 確認程式碼準備好了(測試通過)
git status
# 2. 更新 CHANGELOG.md
# 3. 更新版本號(pyproject.toml 或 __init__.py)
# 4. Commit 版本變更
git add CHANGELOG.md pyproject.toml
git commit -m "chore: bump version to 1.1.0"
# 5. 打 Tag
git tag -a v1.1.0 -m "v1.1.0: 加入查詢歷史功能"
# 6. Push 含 Tag
git push origin main --tags
# 查看所有 Tag
git tag -l
# 回到某個版本
git checkout v1.0.0
在 FastAPI 顯示版本資訊
# pyproject.toml
[tool.poetry]
version = "1.1.0"
# main.py
from importlib.metadata import version
app = FastAPI(
title="天氣小工具",
version=version("weather-app"),
description="查詢即時天氣的 RESTful API"
)
延伸:Conventional Commits 讓 commit 訊息有意義
Conventional Commits 是一個 commit 訊息的規範,格式是 type(scope): description,讓 commit 記錄可讀性更高,也能自動生成 CHANGELOG。
| Type | 用途 | 例子 |
|---|---|---|
| feat | 新功能 | feat: 加入查詢歷史功能 |
| fix | Bug 修復 | fix: 修正城市名稱大小寫問題 |
| docs | 文件更新 | docs: 更新 README 安裝步驟 |
| refactor | 重構(不改行為) | refactor: 把天氣查詢邏輯抽成 service |
| test | 加測試 | test: 加入天氣 API 的整合測試 |
| chore | 雜事(升版本、更新依賴) | chore: bump version to 1.1.0 |
用 AI 生成 CHANGELOG執行 git log v1.0.0..HEAD --oneline 取得 commit 記錄,貼給 AI:「請把這些 commit 整理成 Keep a Changelog 格式的 CHANGELOG,分成 Added、Fixed、Changed 三個區塊」。
延伸學習
知識變現切割地圖(高清版下載,不含講義)
《知識變現切割地圖》的高清完整版。一張圖把語氣、心理、內容、產品、再利用五層模組攤在同一個平面上,讓你回頭盤點已有內容、規劃新的轉化節奏。課程附上地圖本身的完整解說與應用指南,教你怎麼讀這張圖、從哪一層開始用。完整版 PDF 可下載,放大看細節不會糊。
NT$ 680
ChatGPT 很強,但真正讓你下班的是 Google
六小時完整實錄。從「AI 很厲害,為什麼你還是每天加班」這個問題出發,把 Google Workspace 當成真正的工作平台重新設計一次流程 ── Sheets 的資料結構、Drive 與 Docs 的文件流、Gmail 與 Calendar 的通知系統,再用 Apps Script 讓它自己跑起來,最後收斂成一張屬於你自己的 AI 工作能力地圖。
NT$ 4,599
常見問答
專案剛開始,版本號要從幾號開始?
可以從 0.1.0 開始。在 1.0.0 之前,所有版本都是 0.x.x,代表 API 可能隨時改變,沒有向後相容承諾,等第一個穩定版本出現才升到 1.0.0。
改了一個 API 的回傳欄位名稱,算哪一種版本?
算 MAJOR,因為舊的呼叫端程式碼會壞掉,這是破壞向後相容性的變更,例如把 temp 改名成 temperature 就要從 1.2.3 升到 2.0.0。
CHANGELOG 一定要手動寫嗎?
不用全手動。可以用 git log v1.0.0..HEAD --oneline 取得 commit 記錄,貼給 AI 請它整理成 Keep a Changelog 格式,分成 Added、Fixed、Changed 三個區塊。
Git Tag 跟版本號有什麼關係?
Git Tag 是把版本號釘在特定的 commit 上,之後出問題可以用 git checkout v1.0.0 直接回到那個穩定版本,GitHub 上也會對應顯示在 Releases 頁面。

