🎯 什麼情境該想到我
當你「程式碼有進版控，但環境設定、部署腳本、資料庫 schema 都散在各處，出事時既查不出誰改了什麼、也回不去上一個能動的狀態」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：讓版控成為整個系統唯一的事實來源（single repository of truth），能反覆且可靠地重現軟體系統的所有元件——包含應用程式、生產環境與所有預生產環境。
版控是整條價值流所有人的事，包含 QA、Operations、Infosec，而不只是開發者。
必須簽入共用版控庫的資產（書中完整清單）：
- 所有應用程式碼與相依（函式庫、靜態內容等）
- 任何用來建立資料庫 schema、應用程式參考資料的腳本
- 所有環境建立工具與產物（VMware/AMI 映像檔、Puppet 或 Chef recipe 等）
- 任何用來建立容器的檔案（Docker 或 Rocket 的定義／組合檔）
- 所有支援用的自動化測試與任何手動測試腳本
- 任何支援程式打包、部署、資料庫遷移、環境佈建的腳本
- 所有專案產物（需求文件、部署程序、release notes 等）
- 所有雲端組態檔（AWS CloudFormation templates、Microsoft Azure Stack DSC 檔、OpenStack HEAT）
- 任何其他建立「支撐多個服務的基礎設施」所需的腳本或組態資訊（企業服務匯流排、資料庫管理系統、DNS zone 檔、防火牆與其他網路設備的組態規則）
補充判準：
- 光能重現生產環境的舊狀態還不夠，預生產與 build 流程本身也要能重現——所以 build 流程依賴的一切（編譯器、測試工具，以及它們依賴的環境）都要進版控。
- 大型物件不必硬塞進 git：虛擬機映像、ISO、編譯後的二進位檔可放 artifact repository（Nexus、Artifactory）、blob store（S3）或 Docker registry，但要與原始碼一起標記與貼標籤。
- 關鍵研究數據：Puppet Labs 2014 State of DevOps Report 發現，Ops 是否使用版控，是 IT 績效與組織績效最強的預測因子；而且「Ops 有沒有用版控」比「Dev 有沒有用版控」更能預測這兩項績效。
- 為什麼？因為幾乎所有情況下，環境裡可組態的設定項比程式碼裡多上好幾個數量級，所以最需要進版控的其實是環境。
原文：「In fact, whether Ops used version control was a higher predictor for both IT performance and organizational performance than whether Dev used version control.」（L4780–4782）
原文：「Because in almost all cases, there are orders of magnitude more configurable settings in our environment than in our code.」（L4794–4795，接續句為「Consequently, it is the environment that needs to be in version control the most.」跨頁於 L4795–4796）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 進了版控但生產環境仍可被手動改，等於白做——必須配合不可變基礎設施，把「唯一的變更途徑」鎖成版控。
- 憑證與密鑰不在書中這份清單的討論範圍內，別把這條當成「把 secrets 也 commit 進 git」的許可。
- 可以有多個 repository 分放不同型別的物件與服務，不必強求單一 repo；重點是「可重現」而非「檔案都塞同一個地方」。
🔗 相關工具
- 隨選環境與基礎設施即程式碼（環境建置工具與產物是這份清單的第 3、4 項）
- 不可變基礎設施（版控是生產變更的唯一入口，這條是它的前提）
- 主幹開發（版控同時是團隊溝通機制，每日簽入 trunk 才發揮效果）
- DevOps手冊