不管你的公司用什麼 Flow，這套流程和工具組合幾乎都適用。
先講結論
大部分公司的 Git 流程都長得差不多：feature → development → staging → main，不跨層、不回頭。搭配 Commitizen 規範 commit message + Husky 做 hook + conventional-changelog 自動生成 changelog，這套工具組合幾乎是業界標配。
Branch 策略
| Branch | 用途 |
|---|---|
| main/master/prod | 正式版本 |
| staging/uat | Release 前的最後驗收 |
| dev/sit | 整合開發項目 |
| feature/hotfix/release | 依情境建立的臨時分支 |
基本原則：feature → development → staging → main。不跨層，不回頭。
開發流程
# 從 development 開分支，命名帶 issue ID
git checkout development
git checkout -b feature/ISSUE-123-add-login
# 開發完成
git add .
git commit -m "feat: add login feature"
git push -u origin feature/ISSUE-123-add-login
# 在 GitLab/GitHub 上對 development 發 MR分支命名帶 issue ID 這件事看起來囉嗦，但當你要找「這個功能是哪個 branch 做的」的時候，你會感謝自己的。
Commit 規範工具
安裝 Commitizen
# 全域安裝（推薦）
npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
# 之後用 git cz 取代 git commit
git cz搭配 Husky 強制規範
npx husky-init && npm install
npm install --save-dev @commitlint/{config-conventional,cli}
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
npx husky add .husky/commit-msg 'npx --no-install commitlint --edit $1'設定完之後，亂寫 commit message 直接被擋。再也不會有 “fix” “update” “asdf” 這種 commit 了。
Changelog 自動生成
npm install --save-dev conventional-changelog-cli在 package.json 加上：
{
"scripts": {
"changelog": "conventional-changelog -i CHANGELOG.md -s"
}
}跑 npm run changelog 就會根據你的 commit message 自動生成 changelog。這就是為什麼 commit 規範那麼重要 — 垃圾進，垃圾出。
各角色職責
| 角色 | 關注重點 |
|---|---|
| RD | 管好 development 上的開發 |
| Releaser | 管理 staging → main 的流程 |
| Manager/Infra | 規劃退版機制 |
這套流程不是唯一的正確答案，但它是大部分團隊的「安全選擇」。先用這套上手，等團隊成熟了再根據需求調整。