将团队从集中式版本控制迁移到 Git 不仅需要学习新命令。 为了支持分布式开发，Git 以不同于集中式版本控制系统的方式存储文件历史记录和分支信息。 规划和实施从集中式版本控制系统成功迁移到 Git 需要了解这些基本差异。
Microsoft帮助将许多内部团队和客户从集中式版本控制系统迁移到 Git。 此体验基于一贯成功的做法生成了以下指南。
成功迁移的步骤
若要成功迁移，团队应：
- 评估当前工具和进程。
- 选择 Git 分支策略。
- 确定是否以及如何迁移历史记录。
- 维护以前的版本控制系统。
- 从源代码管理中删除二进制文件、可执行文件和工具。
- 在 Git 概念和实践中培训团队。
- 测试迁移到 Git。
评估当前工具和进程
变更版本控制系统自然会因为新工具和做法扰乱开发工作流。 这种中断可能是改进 DevOps 流程的其他方面的机会。
团队应考虑在迁移到新系统时采用以下做法：
持续集成（CI）；每次签入都会触发生成和测试过程。 CI 有助于尽早识别缺陷，并为项目提供强大的安全网。
代码签入前，需进行代码评审。 在 Git 分支模型中， 拉取请求 代码评审是开发过程的一部分。 代码评审是对 CI 工作流的补充。
持续交付（CD） 以自动执行部署过程。 更改版本控制工具需要部署过程更改，因此迁移是采用新式发布管道的好时机。
选择 Git 分支策略
在迁移代码之前，团队应 选择分支策略。
在 Git 中，短期 主题 分支允许开发人员与主分支密切合作并快速集成，避免合并问题。 两种常见的主题分支策略是 GitFlow 和更简单的 变体 GitHub Flow。
Git 不建议长期隔离的功能分支，这些分支往往延迟合并，直到集成变得困难。 通过使用现代 CD 技术（如 功能标志），团队可以快速将代码集成到主分支中，同时仍然对用户隐藏正在进行的功能，直到这些功能完成。
当前使用长期功能分支策略的 Teams 可以在迁移到 Git 之前采用功能标志。 使用功能标志可以最大程度地减少要迁移的分支数，从而简化迁移。 无论他们使用的是功能分支还是功能标志，团队都应记录旧分支和新 Git 分支之间的映射，以便每个人都了解提交新工作的位置。
决定是否迁移历史记录
团队可能会想将其现有的源代码历史记录迁移到 Git。 多个工具声明将所有分支的完整历史记录从集中式工具迁移到 Git。 Git 提交似乎较好地映射到以前版本控制工具使用的变更集或签入模型。
但是，此映射存在一些严重的限制。
在大多数集中式版本控制系统中，分支作为存储库中的文件夹存在。 例如，主分支可能是名为 /trunk 的文件夹，其他分支是 /branch/one 和 /branch/two 等文件夹。 在 Git 存储库中，分支包括整个存储库，因此很难进行 1：1 翻译。
在某些版本控制系统中， 标记 或 标签 是一个集合，可以包含树中的各种文件，甚至是不同版本的文件。 在 Git 中， 标记 是特定时间点整个存储库的快照。 标记不能表示存储库的子集，也不能在不同版本中合并文件。
大多数版本控制系统存储有关文件在版本之间更改方式的详细信息，包括重命名、取消删除和回滚等细化更改类型。 Git 将版本存储为整个存储库的快照，关于文件更改方式的元数据不可用。
这些差异意味着完整历史记录迁移充其量是有损耗的，并且可能会导致误导。 鉴于历史记录导入过程中可能存在的损耗、所需投入的工作量以及使用历史记录的相对罕见，建议大多数团队避免进行导入。 相反，团队应执行 提示迁移，仅将最新分支版本的快照引入 Git。 对于大多数团队来说，时间最好花在迁移领域，这些领域具有更高的投资回报，例如改进流程。
维护旧版本控制系统
在迁移期间和之后，开发人员仍可能需要访问以前的版本控制历史记录。 尽管以前的版本控制历史记录随着时间推移变得不那么相关，但能够引用它仍然很重要。 高度管控的环境可能具有版本控制历史记录的特定法律和审核要求。
尤其是对于仅执行顶端迁移的团队，强烈建议长期维护以前的系统。 将旧版本控制系统设置为迁移后只读。
大型开发团队和管控环境可以将 面包屑 放在 Git 中，这些面包屑指向旧版本控制系统。 一个简单的示例是在 Git 存储库的根目录中，第一个提交的是一个文本文件，该文件在分支尖端迁移之前指向旧版本控制服务器的 URL。 如果许多分支迁移，则每个分支中的文本文件应说明分支如何从旧系统迁移。 对于在迁移项目后开始处理项目且不熟悉旧版本控制系统的开发人员，痕迹导航也很有帮助。
删除二进制文件和工具
Git 的存储模型针对文本文件和源代码版本控制进行优化，后者是紧凑且高度可压缩的。 二进制文件通常很大，一旦将其添加到存储库，它们就会保留在存储库历史记录中，并在将来的每个克隆中保留。 由于 Git 存储历史记录的方式，开发人员应避免将二进制文件添加到存储库，尤其是非常大或经常更改的二进制文件。 迁移到 Git 是从代码库中删除这些二进制文件的机会。
还建议从存储库中排除库、工具和生成输出。 而是使用 NuGet 等包管理系统来管理依赖项。
图标和插图等资产可能需要与特定版本的源代码保持一致。 小型、不经常更改的资产（如图标）不会膨胀历史记录，并且可以直接将其包含在存储库中。 若要存储大型或频繁更改的资产，请使用 Git 大型文件存储 （LFS） 扩展。 有关在 GitHub 中管理大型文件的详细信息，请参阅 管理大型文件。 有关 Azure Repos，请参阅 在 Git 中管理和存储大型文件。
提供培训
迁移到 Git 中最大的挑战之一是帮助开发人员了解 Git 存储更改的方式以及提交表单开发历史记录的方式。 不仅仅是准备一个将旧命令映射到 Git 命令的备忘单就够了。 开发人员需要在集中式线性模型方面停止考虑版本控制历史记录，并了解 Git 的历史记录模型和提交图。
人们以不同的方式学习，因此你应该提供多种类型的培训材料。 使用专家讲师进行基于实验室的实时培训对一些人非常有效。 Pro Git 书籍是一个很好的起点，可供在线免费使用。
可用的免费动手培训课程包括：
组织应努力确定团队中的 Git 专家，帮助他们帮助他人，并鼓励其他团队成员提出问题。
测试迁移
团队更新其流程、分析其代码并训练其成员后，可以迁移源代码。 无论是执行提示迁移还是迁移历史记录，请务必将一个或多个测试迁移迁移到测试存储库。 在进行最终迁移之前，请确保：
- 所有代码文件都会迁移。
- 所有分支都可用。
- 存储库中没有流浪二进制文件。
- 用户具有提取和推送的适当权限。
- 生成成功，所有测试都通过。
迁移代码
在非工作时间进行最终迁移，理想情况下选择里程碑事件之间的自然停机时间。 在冲刺结束时迁移可能会导致在开发人员尝试完成工作时出现问题。 尽量在周末进行迁移，因为这时没有人需要进行签入。
规划将旧版控制系统坚定过渡到 Git。 尝试并行运行多个系统意味着开发人员可能不知道在哪里或如何签入。 将旧版本控制系统设置为只读，以帮助避免混淆。 如果没有此保护，可能需要进行包含临时更改的第二次迁移。
实际迁移过程因要迁移的系统而异。 有关从 Team Foundation 版本控制迁移的信息，请参阅 从 TFVC 迁移到 Git。
迁移核对清单
团队工作流：
- 确定构建将如何运行。
- 确定测试何时运行。
- 开发发布管理过程。
- 将代码评审移至拉取请求中。
分支策略：
- 选择 Git 分支策略。
- 记录分支策略、选择原因以及旧分支映射方式。
History:
- 决定保留旧版本控制运行多长时间。
- 确定需要迁移的分支。
- 如果需要，请创建痕迹导航来帮助工程师导航回旧系统。
二进制文件和工具：
- 标识要从存储库中删除的二进制文件和不可差异文件。
- 确定大型文件（如 Git-LFS）的策略。
- 确定分发工具和库的方法，例如 NuGet。
训练：
- 确定培训材料。
- 规划培训事件、书面材料和视频。
- 确定要充当本地 Git 专家的团队成员。
代码迁移：
- 执行多个测试运行以确保迁移顺利进行。
- 确定并沟通切换时间。
- 创建新的 Git 存储库。
- 将旧系统设置为只读。
- 首先迁移主分支，然后迁移任何其他所需的分支。