Git 工作流程：一個人接案也要養成好習慣

前言

根據我的經驗，很多獨立開發者覺得「一個人做專案不需要 Git 工作流程」。但事實是，好的 Git 習慣在你需要回溯程式碼、部署上線、或之後有人加入協作時，會救你一命。

我的分支策略

一個人接案不需要太複雜的流程，我用的是簡化版的 Git Flow：

main ─────────────────────────── (正式環境)
  │
  ├── develop ────────────────── (開發主線)
  │     │
  │     ├── feature/booking ──── (功能分支)
  │     ├── feature/payment ──── (功能分支)
  │     │
  │     └── fix/date-bug ─────── (修復分支)

規則

• main：永遠是可部署的狀態
• develop：日常開發的主線
• feature/*：新功能都開分支
• fix/*：bug 修復

Commit 訊息規範

我採用 Conventional Commits 格式：

<type>: <description>

feat: 新增訂位表單元件
fix: 修正日期選擇器時區問題
style: 調整首頁 RWD 排版
refactor: 重構訂單計算邏輯
docs: 更新 API 文件
chore: 更新依賴套件

好的 commit 訊息

# ✅ 好
git commit -m "feat: 新增信用卡付款功能，支援綠界 ECPay"
git commit -m "fix: 修正手機版選單無法關閉的問題"

# ❌ 不好
git commit -m "update"
git commit -m "修改了一些東西"
git commit -m "WIP"

日常工作流

開始新功能

# 從 develop 開新分支
git checkout develop
git pull
git checkout -b feature/online-booking

# 開發過程中經常 commit
git add -A
git commit -m "feat: 新增時段選擇 UI"

git add -A
git commit -m "feat: 實作訂位 API 串接"

功能完成

# 合併回 develop
git checkout develop
git merge feature/online-booking
git branch -d feature/online-booking

# 推送到遠端
git push origin develop

準備上線

# develop 合併到 main
git checkout main
git merge develop
git tag v1.2.0
git push origin main --tags

實用指令

暫存變更

做到一半要切換分支處理緊急修復：

git stash
# 處理完後回來
git stash pop

查看歷史

# 精簡版歷史
git log --oneline --graph -20

# 查看某個檔案的修改歷史
git log --oneline -p -- app/Models/Order.php

撤銷變更

# 撤銷未暫存的修改
git checkout -- path/to/file

# 撤銷最後一次 commit（保留修改）
git reset --soft HEAD~1

# 修改最後一次 commit 訊息
git commit --amend -m "新的訊息"

.gitignore 基本設定

# Laravel
/vendor
/node_modules
.env
storage/*.key
/public/hot
/public/storage

# IDE
.idea/
.vscode/
*.swp

# OS
.DS_Store
Thumbs.db

搭配 GitHub

即使是個人專案，也建議推到 GitHub：

• 當作遠端備份
• 搭配 GitHub Actions 做自動化測試和部署
• Issue 功能可以追蹤待辦事項
• 客戶需要時可以加入協作者

與接案流程的關係

在我的接案工作流程中，每個里程碑都會打一個 Git tag。這樣驗收有爭議時，可以明確知道每個階段交付了什麼。

小結

根據我的經驗，養成好的 Git 習慣最大的受益者是未來的自己。三個月後回來看程式碼，清楚的 commit 歷史能讓你快速理解當初的開發脈絡。

如果你需要類似的系統，歡迎聯繫討論。