从TFVC迁移到Git的4个不太明显的原因

Team Foundation Server（TFS）是Microsoft产品，提供了所有必要的功能来支持软件开发过程，例如源代码管理，需求和项目管理以及构建和发布过程。

如今，TFS支持两种类型的源代码管理系统：Team Foundation版本控制（TFVC）和Git。

从表面上看，这两个系统非常相似。 您可以提交代码更改，可以查看更改者的历史记录，还可以还原到源代码的先前状态。

但是，更深入的了解会向您展示系统设计中的一些关键差异-最值得注意的是TFVC提供了一个集中式存储库，而Git建立在一个分散的模型上。

如今，几乎所有新启动的软件项目都使用Git进行源代码管理。 甚至Microsoft都说您应该使用Git进行版本控制，除非您特别需要TFVC中的集中版本控制功能。 因此，TFS中的新项目也默认使用Git。

最初，TFS仅支持TFVC，后来在TFS 2013中添加了对Git作为源代码存储库的支持。

我确信在Git支持可用之前，有很多软件项目是从TFS开始的。 因此，那些项目必须选择TFVC作为源代码管理系统。 由于没有人将它们迁移到Git，因此从那时起，这些项目就一直被TFVC所困。

例如，在我公司中，至少有六个活跃的软件项目正在使用TFVC。 很长时间以来，我们没有看到将它们迁移到Git的需要。

如果您习惯使用TFVC，并且从未真正使用过Git，那么您将不了解微小但至关重要的差异。

使用Git代替TFVC作为源代码存储库有很多好处。 在本文中，我将为您提供四个不太明显的理由，说明为什么这些项目应从TFVC迁移到Git。

与TFVC相比，使用Git的好处

1. Git支持在同一功能上的联合工作

假设您要实现一项新功能，该功能需要数据库中的新表，后端服务中的某些更改以及前端中的一些新页面。 只有完成所有这些更改，新功能才能完整并可以投入生产。

这些任务需要不同的技能集-一些数据库知识，作为后端开发人员的经验以及一些前端技能。 通常，这些技能不是一个人拥有的，因此必须由多个人共同完成才能完成该功能。

这意味着多个人同时处理同一个功能，并且必须在某个时刻共享他们的工作。 因此，每个人都有一个难题，只有将它们放在一起，您的功能才能完整。

与TFVC共享工作

如果团队使用TFVC，则轻松共享不完整的工作非常棘手。 但是，有一种方法可以创建所谓的“平台集”并与其他开发人员共享。

架子集只是您代码的特定版本，尚未提交给分支，但可以与其他开发人员共享。 但是，如果您与队友共享一个架子，他们将无法继续基于该架子进行工作。 他们可以查看它，但是不能将其工作与之集成。 TFVC无法做到这一点。

通常的解决方法是将您未完成的工作提交给分支-称为“ dev”分支。 现在，您正在使用同一功能的队友可以获取该功能，并将其与您的功能集成在一起。

在这种情况下，您的提交很可能包含不完整且可能未经测试的代码，因为只有在开发了该功能的其他部分时才能执行测试。

这不是一个好职位，尤其是对于团队中正在开发完全不同功能的其他开发人员而言。 他们也会获取您不完整且未经测试的代码，因此即使他们使用的是完全不同的功能，也可能会遇到软件的某些不良行为。

与Git分享工作

相反，使用Git的团队通常使用某些版本的功能分支模型 。 对于每个功能，您将创建一个单独的分支，并仅与也在使用同一功能的其他开发人员共享该分支。 每个开发人员都致力于该功能分支，添加他们完成功能所需的部分更改。

只有当每个人都添加了他们的工作，并且功能部件经过测试并完成时，整个功能部件才会合并到dev分支中。 因此，您的dev分支绝不会包含未经测试或不完整的代码。

因此，当多个开发人员共同使用同一功能时，使用TFVC共享不完整的工作非常复杂，而使用Git则很简单。

2. Git允许您更新现有的请求请求

代码审查是开发过程中非常重要的一步，因为它们可以确保更好的代码质量并组成更好的团队 。

在不同类型的代码审查中，许多开发团队默认使用异步类型。 Git和TFVC中都支持此检查过程。

在Git的世界中，人们使用所谓的“拉式请求”来请求有关代码更改的反馈。

TFVC支持“审阅请求”，在某种程度上类似于Git中的拉取请求。

两者具有相同的目的，即与另一位开发人员共享代码更改，以便他们可以查看代码并提供反馈以进行改进。

但是，复审请求和拉取请求之间存在非常关键的差异，这对流程有很大的影响。 让我解释。

使用TFVC更新审阅请求

在TFVC中，从事编码工作的开发人员（或编码人员）可以将尚未提交给分支的代码更改发送给审阅者。 本质上，编码人员与审阅者共享一个架子。

然后，审阅者可以发表评论以改进代码，并将评论标记为“需要工作”。 之后，编码人员进行必要的更改，并且必须创建另一个审阅请求。

这里最大的缺点是第二个审核请求与第一个审核请求没有任何关系。 这意味着审阅者必须审阅所有更改，而不仅仅是最后的改进。 因此，对于每一项改进，审阅者都会收到新的审阅请求，并且必须再次审阅整个事情。

在Git中更新请求请求

相反，在Git中，可以对现有的请求请求添加改进更改。

当您必须基于审阅者的反馈进行改进时，可以将这些更改再次提交到同一分支。 然后，这些更改最终会出现在相同的请求中，并且审阅者只需要审阅那些最后的改进。

这个事实使使用Git时，整个代码复审过程变得更加简单，尤其是当编码员是初级用户并且复审者有很多建议可以改善请求请求时。

在这种情况下，您将有多个代码审阅周期，直到拉取请求足够好并且审阅者满意为止。 在每个周期中，编码人员都会更改现有的请求请求，而审阅者只需要审阅这些更改，而不必从头开始审阅所有内容。

因此，与TFVC中的审阅请求相比，Git中的拉取请求支持多个提交。 如果现有的拉取请求已更改，则仅将另一个提交添加到拉取请求中，审阅者仅需要审阅该其他提交。 这就是为什么Git可以在审查过程中为您节省大量时间和精力，从而使团队效率更高的原因。

3. Git允许审阅者合并

当审阅者批准对代码所做的更改时，这些更改可以合并到主行，通常是dev分支。 在Git世界中，您合并了拉取请求，而在TFVC世界中，您则合并了架子集。 尽管这两个过程看起来非常相似，但是有一个关键的区别：

在TFVC中，审阅者将审阅请求标记为“看起来不错”以批准更改。 但这就是他们所能做的。 审阅者无法自行将审阅请求合并到dev分支。 这必须由编码器作为一个单独的步骤来完成。

审核请求一经批准， 编码人员就必须检出架子集，然后将批准的更改提交给dev分支。 这意味着，尽管编码人员可能已经开始了他们的新任务，但他们被打断了自己执行额外的步骤。

相反，在Git中，审阅者可以在批准请求后立即合并请求。 除非有任何合并冲突，否则编码器根本不需要参与合并，这比规则更多的是例外。

如果您想象一个有经验的编码员每天可能会产生几次拉取请求，那么与TFVC的工作流程相比，简化的Git流程使团队的工作效率更高。

Git为编码员节省了不必要的步骤，因此简化了开发流程。

4. Git避免了大的审查/拉取请求

假设您正在开发一个简单的功能，并且正在扩展现有类的功能。 这是一件容易的事。 您只需要将新方法添加到该现有类中，即可完成操作。

但是，此附加方法为该类增加了新的职责。 因此，您决定重命名该类，以使其他开发人员更容易理解该类在做什么。

当然，您可以使用集成开发环境（IDE）的工具（例如Visual Studio）来重命名该类。 因此，这非常容易，并且重命名是在使用该类的代码中的所有位置自动执行的。

但是，由于该类在代码中的许多不同位置使用，因此最终需要更改20个代码文件。 但是只有一个包含需要审查的重要逻辑。

如果在使用TFVC时遇到这种情况，则可以创建一个审阅请求，其中包含一个架子集中的所有更改。 这意味着审阅者被迫以相同的详细信息审阅所有文件，因为它们不知道从何处着眼。 这不是必需的，并且浪费大量时间。

相反，在Git中，您从一个新的功能分支开始。 然后，您实现新方法并提交那些更改。 之后，在最终创建拉取请求之前，请重命名该类并再次提交。

当审阅者开始审阅时，他们将在拉取请求中看到两个不同的提交。 这带来了两个主要好处。

首先，通过分别检查提交，检查者可以轻松地遵循开发人员创建功能的步骤。

例如，如果拉取请求真的很大，比如说它包含10个提交和30个更改的文件，那么审阅者可以逐个处理每个提交，以遵循开发人员的想法。 这比在不知道不同文件中的哪些更改属于一起的情况下，一个接一个地查看30个已更改文件中的每个文件要容易得多。

其次，审阅者还可以轻松地找出重点放在审阅中的重要事项。

例如，如果提交消息显示“将类X重命名为Y”，并且包含20个修改后的文件，则审阅者可以安全地认为该重命名已由IDE工具正确完成，并且他们不需要集中精力进行审阅。那里。

这意味着将请求分为多个单独的提交，可以更轻松地进行审查。 这是因为审阅者还可以按照时间顺序查看每个提交，从而遵循开发人员的逻辑步骤。 他们还可以过滤掉由IDE工具触发的更改。

Git中的拉取请求可以包含多个提交的事实是我列表中所有功能的最大好处。 它只是使整个代码检查任务效率更高，并为检查者节省了大量时间。

而且，对于TFVC中的大型审核请求，缺少对多个提交的支持是一个主要缺点。 由于审阅者不得不一遍又一遍地审阅同一段代码，因此他们不再关注细节，并且可能会错过一个错误。 这就是为什么甚至代码质量也会下降的原因。

这是为什么您应该从TFVC转到Git的最关键原因。

从TFVC迁移到Git

好消息是，从技术角度来看，从TFVC迁移到Git相当容易。 坏消息是，您需要让您的团队参与这个决定，但是人们通常并不非常喜欢更改。

我已经在另一篇博客文章中介绍了该技术过程，因此让我们在这里着重介绍迁移的人为因素。

如前所述，我目前正在使用TFVC的团队中工作。 这是由于历史原因，因为主要的编码项目大约在10年前就开始了，当时TFS不支持Git。

正如在我的球队没有人使用Git在以前的工作工作过，他们从来没有使用Git的工作后习惯TFVC。 这就是为什么我相信人们不会看到TFVC和Git之间的这些“次要”差异。

但是，我在以前的工作中曾与Git合作过，这是我的幸运职位，因此我确实看到了这些“次要”差异。

因此，我目前正在帮助我的团队从TFVC迁移到Git。 对于此迁移，我们使用以下五步方法，您也可以在自己的迁移过程中遵循以下方法：

步骤1：让人们参与迁移

您团队中的人员应尽早参与迁移的整个过程。 如果您在没有团队的情况下计划和执行所有任务，然后最终只是放弃结果，很可能会得到负面的回应。

有一个不错的石汤故事，或者是沸腾的青蛙故事，它基本上解释了为什么您应该在水还很舒服的情况下让您的团队参与进来，因为每个团队成员都可以为这一变化做出自己的贡献。

出于测试目的进行迁移，并为您的队友提供访问Git存储库（repo）的权限以进行测试和审查。 在您仍然使用TFVC的同时，您已经可以创建Git存储库并迁移代码，因此每个人都可以看到新存储库的外观并进行操作。

步骤2：举办研讨会介绍Git功能

您团队中的某些人以前可能没有与Git合作过。 举办研讨会并向他们展示如何使用Git最重要的功能是一个好主意。 这将使开发人员在使用Git的日常工作中需要了解的内容变得很清楚。

可视化git概念的绝佳工具是http://git-school.github.io/visualizing-git/ 。
使用此工具，您可以轻松地解释如何始终将提交链接到父级。 您还可以显示分支只是指向特定提交的指针，依此类推。

您不能指望每个人都花时间自己学习Git。 每个人都有许多其他工作要做，并且找不到时间，因此您应该计划一个专用的时间来主动地在团队中获取知识。

步骤3：发放Git作弊表

因为有些命令很难记住，特别是如果您是从头开始学习Git的，那么最好提供一份开发人员在日常工作中需要使用的Git命令列表。 这样，您的队友就可以轻松查找重要的Git指令。

步骤4：设定迁移日期

研讨会结束后，团队中的每个人都应该对Git有一些基本的了解。 但是在您将生产仓库中的TFVC真正转换为Git之前，您应该给他们一些时间在迁移的测试存储库上应用他们的知识。

应该有两个星期的时间，以便人们可以在测试仓库中闲逛并提出问题，以防万一。 征求他们的反馈； 也许您错过了教他们一些关键部分的知识。

步骤5：每个人都感到自信时切换到Git

在迁移日期的前几天，请团队中的关键人员聚在一起进行最后一次会议。 在该会话中，您可以讨论他们是否预见到任何阻塞问题。 然后，您可以决定要迁移的是“执行”还是“不执行”。

如果您认为这是一次“尝试”，那么您就可以让关键人员来进行迁移。 并且，如果一切按计划进行，几天后您将切换到Git。 之后，您将享受最佳版本控制系统的新功能。

迁移到Git：似乎并不难

从TFVC迁移到Git并不像您想象的那样困难。 实际上，它的简单和直接让我感到惊讶。 通过仅在控制台中运行一些命令，就可以将TFVC存储库迁移到Git存储库。

新的Git回购将在同一TFS团队项目中。 因此，您可以保留所有相关功能，例如用户故事或内部版本。

例如，您无需对用户故事进行任何处理，因为它们属于同一TFS团队项目。 当然，您需要稍微调整一下构建以使用新的Git存储库，但是TFS中配置的主要部分保持不变。

出于测试目的，您可以同时运行TFVC存储库和Git存储库。 如果您对团队有使用Git的知识充满信心，那么您只需删除一些权限即可锁定TFVC存储库，然后继续在迁移的Git存储库上进行开发。

如您所见，从TFVC迁移到Git有一些主要好处。 最重要的一个事实是，您可以对一个请求请求进行多次提交，从而使整个审核过程更加轻松和有效。 您将获得的仅仅是更高的代码质量。

您还可以更轻松地一起使用某个功能，并且仅在成功测试，检查和构建该功能后，才能合并到主分支。

如果您已经经历了从TFVC迁移到Git的过程，请在评论中分享您的经验。 我非常想知道过渡对您来说有多困难或多么顺利。

好的，如果您的团队仍在使用TFVC，希望我能够说服您切换到Git。 希望在几周后，您和您的团队就可以享受市场上最强大的源代码控制系统的好处。

敬请关注，HabbediEhre！

翻译自: https://www.javacodegeeks.com/2018/09/migrate-tfvc-git.html