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 店面服务未重新启动。因为对应的镜像或配置没有变化。
