我们正在合并到公司的Git中。我们有这种特定的情况，其中我们的主分支是我们的开发分支，每个发行版都是该主分支的分支版本。这些发行版本分为定制的客户版本。因此，我们正在使用单一存储库。
每个分支机构都有几个项目。每个项目都需要自己的ci。我们遇到的第一个问题是gitlab-runner自动克隆整个分支。实际上，这意味着将不必要文件的负载复制到甚至不使用这些文件的项目中。通过在GIT_STRATEGY: none中使用.gitlab-ci.yml，禁用自动克隆并强制我们手动提取.gitlab-ci.yml脚本部分中需要的文件，可以部分解决此问题。
这是使用git的稀疏签出完成的。在本地，一切正常，但是当我们使用gitlab-ci尝试时，由于某种原因，在.gitlab-ci.yml脚本部分中定义的pull请求被卡住了。我们转到服务器，尝试运行相同的“ git pull origin master”命令，该命令使gitlab-runner卡住并发现了问题。拉取请求需要身份验证。
问题1：如何仅使用.gitlab-ci.yml或gitlab-runner的配置来处理请求请求所需的身份验证？我们知道克隆操作有这种身份验证方法，但是就我们所知，克隆并不是真正的选择（因为它总是从分支复制所有内容）：
http://gitlab-ci-token:${CI_JOB_TOKEN}@repository.git
问题2：我们注意到在为新项目运行作业脚本时必须将git初始化为“ init：ed”。很好，很花哨，因为在已经存在的本地存储库上运行git init只会使其重新启动（这不是问题）。但是我们还必须添加我们的遥控器（git remote add origin %repositoryURL%）。这会导致问题，因为运行在git remote add origin中编写的同一.gitlab-ci.yml命令会在ci运行期间导致致命错误，从而导致构建失败。仅在以前已经添加了远程服务器的情况下才会发生这种情况，因此手动删除配置文件可能是一种解决方案？删除不存在的遥控器也会导致致命错误，因此删除->在每次作业运行时添加遥控器都不足够。
感谢您的耐心配合。我们知道这不是最佳解决方案，多重存储会容易得多，但我们确实想保留当前的工作树结构。