我的开发团队很快就会转向分支——我们已经被 SourceSafe 诅咒了，我们正在转向 Team Foundation Server——我很好奇一些事情。
传统上，当我们对产品进行重大修订时，甚至文件夹结构或文件名都不会保持不变，我们会在源代码控制中创建一个新的根文件夹。
例如
$/V1.0
$/V1.1
$/V1.5
$/V2.0
等等。
我对分支是全新的，我正在阅读的一件事是你可以为你的产品的不同版本使用不同的分支。现在，当您谈论对代码进行修补程序或小幅更改或修改时 - 最坏的情况是您可能会添加新文件 - 这是有道理的。
但是，当您制作产品的“V-Next”版本时，您计划或多或少地对产品进行完全重写（不是从头开始，而是彻底重写），直到文件夹结构和文件名称可能会完全不同，这仍然是您想通过分支做的事情吗？或者您想创建一个新的根目录（上面的 $/V2.0）来处理它？
我们的开发团队在 Subversion 中使用了一个非常标准的分支结构。在主存储库中，我们有 3 个文件夹：
在您的示例中，所有 V* 文件夹都将位于标签下。所有主要开发都发生在主干中，当我们需要对另一个项目的主干中的内容进行更改时，我们会使用分支。
我们还使用分支来存储对主干的重大更改。如果您需要在重写完成之前修复主干中的错误，这是一个很好的做法。因此，我们将在分支下创建一个“V-Next”分支，完成后，我们将该分支合并回主干。
我不是 TFS 专家，但我对分支和标签确实有“强烈”的看法。
任何 VCS 中的分支都应保留，以隔离与当前不兼容的开发工作。
这意味着，无论您当前工作的环境（分支或无分支）如何，如果您在启动您提到的那些剧烈重构时无法继续当前的开发，那么您需要一个分支。
在该分支中，您的文件历史记录可以采用新路径，同时仍被记录
诀窍是不要解释分支的标签，特别是如果两者都表示为目录。
V2.0可以解释为：
我会推荐一个命名约定来阐明目录背后的意图：
V2.0_Refactoring例如会更清晰并指示一个分支。
分支将您的历史记录在一起，并允许您查看项目的完整起源。此外，可能（取决于产品和混乱状态）将已发布版本中的修复合并到“下一个”版本中，这可能会或可能不会减少保持同步的工作。
根据我的经验，最有效的分支策略是有一个单一的“主线”主干，每个主要版本的分支，然后根据需要为每个较小的版本分支。大多数工作都是在主线中完成的，然后当我们非常接近发布时，我们会分支并稳定分支。
您可以为任意小的变更集/发布分支，但最终会产生过多的认知开销，使它们变得有价值。您还可以创建更多临时分支以将大型正在进行的工作与主要分支隔离，直到准备好合并更改。
以所有这些作为背景，我认为在发布开始时“重新开始”没有多大价值。即使在发布结束时一切都将发生变化，您仍然希望了解事情如何随着时间的推移而演变的完整历史。我假设 TFS 会跟踪移动/重命名/删除等，因此即使您正在进行大量文件级更改，这也是宝贵的历史记录。
您可能想查看一些有关最佳实践的文章：
在您的情况下，我不会创建一个分支来托管您的 V-next。只有当您准备好通过创建包装分支向客户交付时，您才应该创建该分支。
我会创建一些短期分支（每个 scrum 迭代 1 个）来托管您的风险开发，并在每次迭代结束时将它们合并回来。只为有风险的开发创建开发分支，例如您正在谈论的密集重构。
你的主分支应该总是稳定的。准备好交付给客户或至少准备扩展包装分支。
我还推荐SCM 模式。