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