如何在Azure DevOps中引用外部仓库？实现类似SVN Externals的功能

Git仓库场景（Azure DevOps Git） #

如果你的项目用的是Azure DevOps Git仓库，对应SVN Externals的功能是Git子模块（Git Submodules），操作逻辑如下：

• 先把共享组件推到新的Azure DevOps Git仓库，然后在主项目仓库里执行命令添加子模块：

  git submodule add <共享项目的Azure DevOps Git仓库地址> <本地存放共享代码的路径>
  

• 提交并推送这个变更后，其他开发者克隆主项目时，加--recursive参数就能自动拉取共享项目：

  git clone --recursive <主项目仓库地址>
  

  要是已经克隆了主项目，执行git submodule update --init --recursive也能补拉共享代码。
• 提交变更时：主项目的改动直接提交推送到主仓库即可；共享项目的改动需要进入子模块目录，单独提交推送到共享仓库，主项目里只会记录子模块当前的提交哈希，记得同步更新主项目里的子模块引用提交。

另外还可以用Git子树（Git Subtree），它是把共享仓库的内容合并到主仓库的一个目录下，提交时直接在主仓库里提交共享目录的变更，再推送到共享仓库就行，适合不想单独维护子模块提交记录的场景，命令示例：

git subtree add --prefix=<本地共享目录路径> <共享项目仓库地址> <分支名>

TFVC仓库场景（Azure DevOps TFVC） #

如果用的是TFVC版本控制，对应功能是TFVC工作区映射，逻辑和SVN Externals几乎一致：

• 在TFVC的工作区设置里，除了映射主项目的服务器路径到本地，再新增一条共享项目的服务器路径到本地目录的映射，这样获取代码时会自动拉取共享项目。
• 提交变更时，直接在本地对应的目录提交，TFVC会自动识别对应的服务器路径，把改动提交到各自的项目仓库。

小提示 #

• Git子模块需要团队成员熟悉基本操作，避免出现子模块版本不一致的问题；子树相对更简单，但共享项目的版本追踪不如子模块清晰。
• TFVC的映射方式最贴合SVN用户的使用习惯，上手成本最低。

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