SAP Commerce Cloud 使用單個 Git 儲存庫作為專案 Customization 的來源，採用單一構建過程來構建整個應用，並且將整個應用程式的構建結果，採用單一部署過程部署到目標環境。
Commerce Cloud 構建過程使用遞迴選項克隆專案儲存庫。它允許您將其他儲存庫（稱為Sub modules）插入主儲存庫。 當多個團隊為同一個專案儲存庫做出貢獻時，這種方法很有用。 每個儲存庫可以使用不同的分支策略或具有不同的許可權規則。
從 Commerce Cloud 的角度來看，這種方式仍然像單個儲存庫一樣工作：
- Commerce Cloud 構建過程會克隆主儲存庫的給定分支的最近提交。
- 主儲存庫的某一個路徑，可以指向特定路徑和單獨儲存庫（git 子模組）的特定提交。
所有單獨的儲存庫都使用相同的憑據進行訪問，這些憑據在 Cloud Portal 中為主儲存庫配置。
看個具體的例子。
有一個專案儲存庫，它包括下列資源：
- core Customization 核心定製，其中儲存在子模組 1 中的擴充套件 1 和 2，擴充套件 3 和 4 儲存在子模組 2 中。
- JavaScript 店面儲存在子模組 3 中。
在某個時間點，開發人員更改了子模組 1 中的擴充套件 1。
- 為了反映主儲存庫中的更改，還必須對主儲存庫進行提交，更改對子模組 1 的引用，以指向其最近的更改。
- 終端使用者觸發 Commerce Cloud 中的新構建。
構建過程進行的變更分析和檢測：
- 必須構建新的平臺映象，因為擴充套件 1 發生了變化。
- 可以重複使用現有的 Solr 映象，因為作業系統、Solr 或 Commerce Cloud 版本沒有變化，Solr 定製沒有變化。
- 可以重複使用現有的 Zookeeper 映象。因為作業系統或 Zookeeper 版本沒有變化。
- 可以重複使用現有的 JavaScript 店面映象。 JavaScript 店面自定義沒有變化。
終端使用者觸發新構建的部署：
- 有一個新的平臺映象，因此所有基於平臺的服務都將重新啟動。
- Solr 和 Zookeeper 服務不會重新啟動。因為對應的映象或配置沒有變化。
- JavaScript 店面服務未重新啟動。因為對應的映象或配置沒有變化。