Vibe Coder

版本號怎麼升?語意化版本與 CHANGELOG 入門

語意化版本號的格式是 MAJOR.MINOR.PATCH:修 bug 升 PATCH、加新功能且向後相容升 MINOR、有破壞性改動升 MAJOR。搭配 CHANGELOG 記錄每個版本改了什麼,再用 git tag 標記發布點,之後出問題一個指令就能回到上一個穩定版本。
版本號怎麼升?語意化版本與 CHANGELOG 入門

版本號怎麼升?語意化版本與 CHANGELOG 入門

三個月後你不會記得哪個版本加了什麼功能,除非有人幫你記。版本號和 CHANGELOG 就是那個記憶外掛:版本號讓你知道自己改了什麼,CHANGELOG 讓客戶和使用者也知道。這篇帶你搞懂語意化版本怎麼升、CHANGELOG 怎麼寫,以及完整的 Git Tag 發布流程。

你將學到什麼

MAJOR.MINOR.PATCH

三段式版本號各自代表什麼改動,一張表看懂該升哪一段。

什麼時候升哪個號碼

從修 bug 到改欄位名稱,六種常見情境的對照答案。

CHANGELOG 的格式

Keep a Changelog 風格範本,Added、Fixed 分類一目瞭然。

Git Tag 發布流程

從確認測試通過到 push 帶 tag,六個步驟走一遍。

語意化版本:MAJOR.MINOR.PATCH

2MAJOR不相容的改動.4MINOR新增功能(相容).1PATCH修 bug(相容)
版本號 2.4.1 拆解:MAJOR 不相容改動、MINOR 新增功能、PATCH 修 bug。
部分什麼時候升例子
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)PATCH1.2.3 → 1.2.4
加了一個新的 API 端點MINOR1.2.3 → 1.3.0
把 /weather 改成 /api/weatherMAJOR(破壞現有使用者)1.2.3 → 2.0.0
改了一個 API 的回傳欄位名稱MAJOR(舊的程式碼會壞)1.2.3 → 2.0.0
改善效能但行為不變PATCH1.2.3 → 1.2.4
加了選填的 query parameterMINOR(向後相容)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: 加入查詢歷史功能
fixBug 修復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 三個區塊」。

延伸學習

把這篇文章分享給需要的人FacebookLINEThreadsX

常見問答

專案剛開始,版本號要從幾號開始?
可以從 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 頁面。