Git 流程規劃

1. 目的 (Objective)

• 版本控制: 透過 Git，可以在開發過程中記錄每一次程式碼變更，保留歷史紀錄，便於追溯和復原。這對於回溯到某個特定版本或修復特定問題非常有用。

• 協作開發: Git 支援多人同時進行開發，開發人員可以在各自的分支上進行工作，然後將變更合併到主分支或開發分支，避免程式碼衝突。

• 質量控制: 透過分支策略和 Pull Request 流程，可以確保每一次合併都經過程式碼審查和測試，保證程式碼的質量和穩定性。

• 備份與還原: 程式碼儲存於分散式版本控制系統中，提供了資料備份和還原的功能，降低了資料丟失的風險。

2. 效益 (Benefits)

• 高效協作: 多人協同開發不再依賴中央服務器，每個人都有完整的程式碼庫拷貝，可以隨時進行開發，並在合適的時機進行合併。

• 清晰的開發流程: 使用分支策略和標記機制，可以明確區分開發中的功能、測試版本和穩定版本，使得整個開發流程有條不紊。

• 快速回溯與修復: 在出現問題時，可以迅速回溯到之前的穩定版本，或者修復後通過快速熱修補分支進行部署。

• 版本發布的自動化: 結合 CI/CD 工具，可以自動化構建、測試和部署過程，減少人為錯誤，提高發布效率。

3. 角色 (Roles)

• Maintainer (維護者): 負責主要分支的管理和程式碼審查，控制對 main 和 develop 分支的合併權限，確保程式碼質量和穩定性。

• Developer (開發者): 在功能分支上進行開發工作，負責提交程式碼、創建 Pull Request，參與程式碼審查和測試。

• Release Manager (發布經理): 負責管理發布分支，準備和發佈新版本，標記版本號，並確保發佈過程順利進行。

• Guest (訪客): 僅能查看程式碼和版本歷史，不具備推送權限，通常是對開發流程感興趣的觀察者或客戶。

4. 管理 (Management)

• 分支管理: 設定並維護好分支策略，確保每個功能分支、修補分支、發布分支都有明確的用途，並遵循相應的合併流程和審查流程。

• 權限管理: 設置適當的權限，保護關鍵分支如 main 和 develop，限制推送權限給有經驗的維護者，同時開放功能分支給開發者進行創新和嘗試。

• 程式碼審查: 執行嚴格的程式碼審查流程，確保每一行程式碼在合併到主分支之前，都能經過充分的審查和測試，以降低錯誤和問題的風險。

• 自動化測試: 結合 CI/CD 系統，設置自動化測試流程，確保每次程式碼提交後，系統會自動運行測試，快速發現和修復問題。

• 版本管理: 使用 Git 的標記功能標記每個發佈的穩定版本，記錄版本歷史，並在必要時可以回滾到之前的穩定版本。

• 備份策略: 定期備份 Git 儲存庫，確保即使在極端情況下（如資料庫崩潰），也可以快速恢復所有程式碼和版本歷史。

5. 實作

5.1. 分支策略

• 主分支 (Main/Production Branch)

  • 分支名稱: main 或 master

  • 用途: 存放穩定的、隨時可以發佈的程式碼。所有在此分支上的程式碼都必須通過完整的測試和程式碼審查。

  • 操作限制: 只有少數幾個授權人員可以直接推送程式碼到 main 分支。

• 開發分支 (Development Branch)

  • 分支名稱: develop

  • 用途: 作為日常開發的主要分支，所有新功能和修正都應先合併到此分支，再進行集成測試。

  • 操作限制: 團隊成員可以推送到此分支，但需要進行基本測試和程式碼審查。

• 功能分支 (Feature Branches)

  • 分支名稱: feature/xxx (如 feature/user-authentication)

  • 用途: 每個新功能、改進或修正都應該在自己的功能分支中進行開發，分支從 develop 派生，完成後合併回 develop。

  • 操作限制: 團隊成員自由創建功能分支，完成後需提交 Pull Request (PR) 並進行程式碼審查。

• 修補分支 (Hotfix Branches)

  • 分支名稱: hotfix/xxx (如 hotfix/urgent-bug)

  • 用途: 當發現嚴重的生產環境問題時，從 main 或 develop 派生此分支，修補完成後合併回 main 和 develop。

  • 操作限制: 僅限緊急修正使用，需快速合併並發佈。

• 發布分支 (Release Branches)

  • 分支名稱: release/xxx (如 release/1.0.0)

  • 用途: 當 develop 分支準備好發佈版本時，創建發布分支，進行最終測試和版本控制，完成後合併回 main 並標記版本號。

  • 操作限制: 僅在版本準備發佈時使用，且程式碼必須通過所有測試。

5.2. 提交訊息規範

• 格式範本: [類型]: [簡短描述]

  • fix: 修復 bug

  • feat: 新功能

  • refactor: 程式碼重構

  • docs: 文檔變更

  • style: 程式碼格式（不影響程式碼邏輯的變更）

  • test: 添加或修改測試

  • chore: 雜項（如構建過程或輔助工具的變更）

• 範例:

  • fix: 修復登錄頁的崩潰問題

  • feat: 添加用戶權限管理功能

  • refactor: 優化資料處理邏輯

5.3. 程式碼審查流程

• Pull Request (PR) 流程

  1. 創建 PR: 完成功能或修復後，從功能分支向 develop 提交 PR。

  2. 自動化測試: PR 創建後，自動化測試工具會自動運行測試套件，確保程式碼不會引入新問題。

  3. 程式碼審查: 至少兩位開發人員審查程式碼。審查內容包括程式碼質量、邏輯正確性、風格一致性等。

  4. 合併 PR: 審查通過後，負責人將 PR 合併到 develop 分支。

  5. 刪除分支: PR 合併後，刪除功能分支以保持分支管理的清晰度。

5.4. 版本發布流程

• 版本標記

  • 當準備發佈新版本時，從 develop 創建一個 release 分支，進行最終測試和修正。

  • 測試通過後，將 release 分支合併到 main，並使用 Git 標記版本號 (git tag v1.0.0)。

  • 發佈後，合併 release 分支到 develop，確保 develop 包含最新的修正和變更。

5.5. 備份與還原

• 定期備份: 設置自動化工具定期備份 Git 儲存庫，以防止資料丟失。

• 還原機制: 如果發生緊急狀況，可以使用 Git 的 revert 或 reset 命令還原到之前的穩定版本。

5.6. 權限管理

• 設定團隊角色:

  • Maintainer: 具備推送到 main 和管理設定的權限。

  • Developer: 只能推送到 develop 或功能分支，並參與 PR 審查。

  • Guest: 只能查看專案，不具備推送權限。

• 分支保護:

  • 設置 main 和 develop 分支的保護策略，禁止未經審查的程式碼直接推送到這些分支。

Git流程圖-main