版本控制基本概念：Git 工作流程與最佳實務

版本控制系統讓開發者可以追蹤變更、回溯錯誤、並行工作並保留完整歷史。Git 是目前最廣泛使用的分散式版本控制工具。本文介紹核心概念與日常實務。

核心概念

儲存庫（repository）保存專案的完整歷史。工作目錄是你正在編輯的檔案。暫存區（staging area）讓你可以選擇哪些變更要納入下一次提交。提交（commit）是某個時間點的快照，附有訊息、作者與父提交指標，形成有向無環圖。

分支（branch）是指向某提交的可移動指標。建立分支成本極低，因此鼓勵用分支進行實驗或功能開發，而不直接在主分支上修改。合併（merge）把一個分支的變更整合到另一個分支。當雙方修改了相同區域時可能產生衝突，需要手動解決。

基本工作流程

1. 從遠端取得最新變更（fetch / pull）。
2. 建立功能分支進行修改。
3. 多次小提交，保持每個提交聚焦且可理解。
4. 推送分支並開啟合併請求（pull request）進行審查。
5. 審查通過後合併到主分支，並刪除已完成的功能分支。

個人專案也可以採用類似流程，只是審查步驟可簡化。重點是保持歷史清晰、可回溯。

提交訊息與歷史品質

好的提交訊息說明「為什麼」做這個變更，而不只是「改了什麼」。常見格式包含簡短主旨行與必要的正文。原子提交（一個提交只做一件事）讓回溯與挑選（cherry-pick）更容易。避免把無關變更混在同一個提交裡。

強制推送（force push）會改寫遠端歷史，可能影響其他人，應謹慎使用並提前溝通。已發布的主分支歷史通常不應改寫。

常見實務建議

• 經常提交與推送，減少遺失工作的風險。
• 使用 .gitignore 排除建構產物、密鑰與環境特定檔案。
• 密鑰與憑證絕不應提交到儲存庫。若意外提交，應立即撤銷並更換。
• 大型二進位檔案考慮使用 Git LFS 或外部儲存。
• 定期檢視與清理不再需要的分支。

與協作工具的關係

GitHub、GitLab 等平台在 Git 之上提供議題追蹤、程式碼審查、持續整合等功能。核心仍是 Git 的提交與分支模型。理解底層概念有助於正確使用這些平台，並在出現問題時自行診斷。

Wusper 本身的開發亦採用 Git 進行版本管理，強調小批次、可驗證的變更與清晰的提交歷史。本文為一般性介紹，具體指令與進階主題（變基、子模組、稀疏簽出等）可參考官方文件進一步學習。