Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
可以将代码从现有的 Team Foundation 版本控制（TFVC）存储库迁移到同一组织中的新 Git 存储库。 对于大型 TFVC 存储库和团队来说，迁移到 Git 是一个复杂的过程。 TFVC 等集中式版本控制系统在本质上与 Git 有所不同。 这种转换涉及的不仅仅是学习新的命令。 这是一项中断性变更，需要仔细规划。 需要考虑以下事项：
- 修订工具和流程
- 移除二进制文件和可执行文件
- 培训团队
先决条件
| 类别 | 要求 |
|---|---|
| 项目访问权限 | 项目的成员。 |
| 权限 | - 查看专用项目中的代码：至少 是基本 访问权限。 - 克隆或参与专用项目中的代码： 参与者 安全组的成员或项目中的相应权限。 - 设置分支或存储库权限： 管理 分支或存储库的权限。 - 更改默认分支： 编辑存储库的策略 权限。 - 导入存储库： 项目管理员 安全组的成员或 Git 项目级 “创建存储库 ”权限设置为 “允许”。 有关详细信息，请参阅设置 Git 存储库权限。 |
| Services | 已启用存储库。 |
| 工具 | 可选。 使用 az repos 命令： Azure DevOps CLI。 |
注释
在公共项目中，具有 利益干系人 访问权限的用户具有对 Azure Repos 的完全访问权限，包括查看、克隆和参与代码。
强烈建议在开始迁移之前，先从 TFVC 到 Git 部分读取 集中版本控制 ，然后再 从 TFVC 迁移到 Git 部分。
导入体验非常适合小型简单的 TFVC 存储库。 它还适用于已清理的存储库，如 集中版本控制到 Git 和 从 TFVC 迁移到 Git 部分中所述。 这些部分还为更高级的 TFVC 存储库配置推荐了其他工具。
重要
由于 TFVC 和 Git 应用商店版本控制历史记录存在差异，我们建议不要迁移历史记录，这是将 Windows 和其他产品从集中式版本控制迁移到 Git 时Microsoft采用的方法。
导入存储库
依次选择“存储库”、“文件”。
查看分支在存储库下拉列表中，选择“导入存储库”。
导入存储库选项从“源类型”下拉列表中选择“TFVC”
键入要导入到 Git 存储库的存储库/分支/文件夹的路径。 例如：
$/Fabrikam/FabrikamWebsite如果要从 TFVC 存储库迁移历史记录，请选择 “迁移历史记录 ”，然后选择天数。 从最近的变更集开始，最多可以迁移 180 天的历史记录。 TFVC 存储库的链接将添加到迁移到 Git 的第一个变更集的提交消息中，这样就可以轻松地在需要时查找较旧的历史记录。
为新的 Git 存储库命名，然后选择“ 导入”。 根据导入的大小，Git 存储库将在几分钟内准备就绪。
导入存储库对话框
故障排除
此体验针对为迁移准备的小型、简单的 TFVC 存储库或存储库进行了优化。 这意味着它存在几个限制。
- 它仅迁移根或分支的内容。 例如，如果你有一个 TFVC 项目
$/Fabrikam，其下有一个分支和一个文件夹，则导入的路径将导入$/Fabrikam该文件夹，而$/Fabrikam/<branch>只会导入分支。 - 导入的存储库和关联的历史记录（如果导入）的大小不能超过 1 GB。
- 你可以导入最多 180 天的历史记录。
如果上述任一信息是导入的阻止程序，我们建议尝试使用 Git-TFS 等外部工具导入和读取白皮书 - 集中版本控制到 Git ，以及以下 从 TFVC 迁移到 Git 部分。
重要
将外部工具（如 Git-TFS）用于 Microsoft 产品、服务或平台完全由用户负责。 Microsoft不支持、支持或保证此类非Microsoft扩展的功能、可靠性或安全性。
从 TFVC 迁移到 Git
在将源代码从集中式版本控制系统迁移到 Git 之前，请了解这两者之间的差异并 准备迁移。
要求
为了简化迁移，在遵循本文上一部分中 导入存储库 过程之前，有许多要求。
- 仅迁移单个分支。 规划迁移时，为 Git 选择新的分支策略。 仅迁移主分支支持基于主题分支的工作流，例如 Gitflow 或 GitHub Flow。
- 执行提示迁移，就像仅导入最新版本的源代码一样。 如果 TFVC 历史记录很简单，可以选择迁移一些历史记录，最长为 180 天，以便团队只能从 Git 中工作。 有关详细信息，请参阅规划 Git 迁移。
- 从存储库中排除二进制资产，例如图像、科学数据集或游戏模型。 这些资产应使用导入工具未配置的 Git LFS（大型文件存储）扩展。
- 将导入的存储库的大小保持在 1 GB 以下。
如果存储库不符合这些要求，请改用 Git-TFS 工具执行迁移。
重要
将外部工具（如 Git-TFS）用于 Microsoft 产品、服务或平台完全由用户负责。 Microsoft不支持、支持或保证此类非Microsoft扩展的功能、可靠性或安全性。
Migrate
从 TFVC 迁移的过程非常简单：
- 从本地磁盘上的 TFVC 中查看最新版本的分支。
- 从存储库中删除二进制文件和构建工具，并设置程序包管理系统（如 NuGet）。
- 转换特定于版本控制的配置指令。 例如，将
.tfignore文件转换为.gitignore文件，并将.tpattributes文件转换为.gitattributes。 - 签入更改并执行 Git 迁移。
步骤 1 到 3 为可选步骤。 如果存储库中没有二进制文件，并且无需设置 .gitignore 或 .gitattributes，则可以直接转到签入更改并执行迁移步骤。
查看最新版本
创建新的工作区，并为要迁移到 Git 的服务器目录映射工作文件夹。 此作不需要完整的工作文件夹映射。 只需映射包含要从存储库中删除的二进制文件的文件夹，以及包含版本控制特定于系统的配置文件的文件夹，例如 .tfignore。
设置映射后，在本地获取该文件夹：
tf get /version:T /recursive
删除二进制文件和构建工具
由于 Git 通过向每个开发人员提供历史记录中每个文件的副本来存储已更改文件的历史记录，因此直接将二进制文件签入存储库可能会导致存储库快速增长并导致性能问题。
对于构建工具和依赖关系（例如库），请采用带版本控制支持的打包解决方案，例如 NuGet。 NuGet 库中已提供很多开源工具和库，但对于专有依赖关系，请创建新的 NuGet 包。
将依赖项移动到 NuGet 后，请确保它们不会包含在 Git 存储库中，方法是将其添加到 .gitignore其中。
转换特定于版本控制的配置
Team Foundation 版本控制提供一个 .tfignore 文件，它可确保不将某些文件添加到 TFVC 存储库。 可将 .tfignore 文件用于自动生成的文件（例如构建输出），以免不慎签入这些文件。
如果项目依赖于此行为，请将 .tfignore 文件转换为 .gitignore 文件。
跨平台的 TFVC 客户端还为 .tpattributes 文件提供支持，该文件可控制如何在本地磁盘上放置文件或将文件签入存储库。 如果正在使用 .tpattributes 文件，请将其转换为 .gitattributes 文件。
签入更改并执行迁移
签入用于删除二进制文件、迁移到包管理或转换特定于版本控制的配置的所有更改。 在 TFVC 中进行此最终更改后，可以 执行导入。
高级迁移
Git-TFS 工具是 TFVS 和 Git 之间的双向桥，可用于执行迁移。 Git-TFS 适用于带完整历史记录（支持比导入工具所支持的 180 天更长时段内的记录）的迁移。 或者，可使用 Git-TFS 尝试执行包含多个分支和合并关系的迁移。
在使用 Git-TFS 尝试迁移之前，请注意 TFVC 和 Git 存储历史记录之间的以下基本差异：
- Git 将历史记录存储为存储库的快照，而 TFVC 会记录文件中出现的离散操作。 TFVC 中的更改类型（如重命名、取消删除和回滚）无法在 Git 中表示。 它只跟踪
A文件已删除，且在同一提交中添加了B文件，而不会看到A文件已重命名为B文件。 - Git 不提供 TFVC 标签的直接模拟。 标签可包含任意特定版本的任意数量的文件，并可反映不同版本的文件。 虽然在概念上类似，但 Git 标记会指向某个时间点的完整存储库快照。 如果项目依赖于 TFVC 标签来了解交付的内容，Git 标记可能无法提供此信息。
- TFVC 中的合并发生在文件级别，而不是整个存储库。 只能将已更改文件的子集从一个分支合并到另一分支。 然后，后续更改集中可能会合并剩余的已更改文件。 在 Git 中，合并会影响整个存储库，且无法将这两组单独的更改视为合并。
由于这些差异，我们建议你执行提示迁移并将 TFVC 存储库保持联机，但只读，以便查看历史记录。
若要尝试使用 Git-TFS 进行高级迁移，请参阅 克隆带历史记录的单个分支或克隆带合并历史记录的所有分支。
重要
将外部工具（如 Git-TFS）用于 Microsoft 产品、服务或平台完全由用户负责。 Microsoft不支持、支持或保证此类非Microsoft扩展的功能、可靠性或安全性。
更新工作流
从集中式版本控制系统迁移到 Git 不仅仅是迁移代码。 团队需通过培训来了解 Git 与现有版本控制系统的不同之处，以及这些差异如何影响日常工作。
详细了解如何从集中式版本控制迁移到 Git。