结合你描述的80GB TFVC仓库、10条经典构建流水线（暂无法用YAML）、存在共用文件夹的场景，我优先推荐单仓库迁移方案，同时帮你解决“无法配置工作区映射”的核心痛点；如果后续有模块拆分需求，再考虑多仓库的优化方案，下面详细说明：

一、优先选择：单仓库迁移（解决工作区映射+共用文件夹问题） #

你提到单仓库迁移时无法配置工作区映射，其实是对Git经典流水线的路径配置不熟悉——Git的经典流水线完全可以用路径包含/排除替代TFVC的工作区映射，而且git-tfs迁移时也能精准控制要迁移的内容，具体步骤如下：

1. 先给TFVC仓库“瘦个身”（可选但强烈推荐） #

80GB的仓库直接迁移到Git会导致仓库体积过大，后续拉取、维护都很麻烦。你可以先清理TFVC里的冗余内容：

• 删除历史中不再需要的大二进制文件（比如旧的安装包、日志），用TFVC的历史清理工具或者git tfs cleanup命令移除这些文件的所有历史记录。
• 确认不需要迁移的分支、文件夹，提前在TFVC工作区中排除，减少迁移范围。

2. 用git-tfs精准迁移（匹配原工作区映射） #

• 先在TFVC中创建一个专用迁移工作区，配置和现有10条流水线完全一致的工作区映射（包括共用文件夹的映射规则）。
• 进入这个工作区的本地目录，执行迁移命令：

  git tfs clone http://你的TFVC服务器地址/tfs/集合名 $/你的项目根路径 --branches=auto
  

  这个命令会严格按照你配置的工作区映射来拉取文件和历史，不会迁移超出范围的内容。如果只需要特定分支，也可以加上--branch=$/分支路径指定。

3. 适配经典构建流水线（替代工作区映射） #

迁移完成后，把现有流水线的源代码源切换到新的Git仓库：

• 在流水线的「获取源代码」步骤中，找到路径包含/排除配置项：
  • 把原来TFVC工作区映射的路径，转换成Git的相对路径，比如原映射$/Project/ModuleA和$/Project/Shared，就填ModuleA/**, Shared/**作为路径包含；
  • 不需要的路径可以填在排除框里，完全复刻原工作区的效果。
    这样就解决了你说的“无法配置工作区映射”的问题，Git经典流水线的路径过滤功能和TFVC的工作区映射是等价的。

4. 共用文件夹的优势 #

单仓库里共用文件夹只存一份，所有流水线都能直接引用，不需要在多个仓库里重复维护，避免了后续同步更新的麻烦——这是单仓库最大的优势，能减少很多运维成本。

二、备选方案：多仓库迁移（用子模块/子树解决共用文件夹重复问题） #

如果因为业务拆分、权限管控等原因必须分成多仓库，那可以用Git的子模块或子树来避免共用文件夹重复存储：

1. 拆分迁移步骤 #

• 先把共用文件夹$/Project/Shared单独迁移成一个独立的Git仓库，保留完整历史。
• 再把每个业务模块（比如$/Project/ModuleA、$/Project/ModuleB）分别迁移成独立的Git仓库。

2. 关联共用文件夹 #

• 子模块方式：在每个业务仓库中执行：

  git submodule add <共用仓库的Git地址> Shared
  

  这样共用文件夹以子模块的形式存在，每个业务仓库引用共用仓库的特定版本，不会重复存储内容。在流水线的「获取源代码」步骤中，勾选「获取子模块」就能自动拉取共用内容。
• 子树方式：如果希望共用内容成为业务仓库的一部分，执行：

  git subtree add --prefix=Shared <共用仓库的Git地址> main
  

  这种方式适合不需要单独维护共用仓库版本的场景，共用内容会合并到业务仓库中。

3. 适配流水线 #

每个业务仓库的流水线只需要配置对应模块的路径包含，共用文件夹通过子模块/子树自动获取，不需要重复指定。

最终建议 #

优先选单仓库迁移，原因很简单：

1. 迁移步骤更简单，后续维护成本低，共用文件夹不用重复处理；
2. 经典流水线的路径过滤完全能解决你提到的工作区映射问题；
3. 如果后续业务需要拆分模块，还可以用git filter-repo工具把单仓库拆分成多仓库，同时保留完整历史，相当于先完成迁移，再做优化。

内容的提问来源于stack exchange，提问作者Kart