我们有一个巨大的产品，它有很多功能，每个功能都需要很长时间，所以我们在 TFS 中维护短期功能分支。例如，
MAIN/
PROJECTMGT
EMAILMGT
etc..
一旦完成，它们就会 merge 回 MAIN，每个不同的开发团队在不同的分支上工作。
merge 过程
由于每个团队在不同的分支上工作，因此没有冲突，但是负责将分支 merge 到 MAIN 的人员需要清楚地查看不同文件夹中的文件。因为我们需要在 merge 前对分支进行测试和审核，所以我们也需要看到不同分支的冲突并明确解决。
现在我们正在转向 git，在我学习 git 的过程中，我在如何组织分支方面遇到了一些困难。在处理文件和文件夹结构时，我们不知道我们实际位于哪个分支。
我们刚刚在 git 上跑了一个测试，我们大多数在多个分支上操作的人都感到困惑，我们在 merge 时也犯了错误。
TFS 自动将所有内容 merge 到文件实际所属的同一分支，而无需指定分支。
我正在阅读这篇文章，我看到了一些创建多个克隆来模拟 TFS 类型的物理文件夹分支的建议。
有人可以指导我怎么做吗？我正在使用 Visual Studio Tools for Git。
更新
根据评论，这是我们目前的困难。
每个分支都有单独的 NuGet 包版本，例如一个分支可能使用 EF 5 而新分支使用 EF 6，切换分支很痛苦，因为它需要 nuget 恢复及其所有警告。
就像 nuget 包一样，我们在不同的分支中有其他第三方库(二进制文件)和不同版本。
在 merge 时，一团糟，我们一直在问自己我们在哪个分支，但是在 VS 中很容易，因为物理文件夹路径告诉我们我们的分支。
我发现三天前退房时记住我们在哪个分店是完全愚蠢的。虽然当您进入源代码资源管理器时 VS Git 工具会显示它，但当我们打开多个 VS 实例时，这也会失败。
我们正在寻找一种从未使用过“SWITCH BRANCH”的工作流程。
最佳答案
根据对问题的评论，这将是关于如何创建多个克隆(可能 checkout 不同的分支)的答案。
但是，这很可能不是最佳解决方案，原因如下:
每个额外的克隆使用额外的驱动器空间。
使用额外的克隆可能不是使 merge 更容易的最佳方法。 在 git 中以这种方式处理 merge 问题是非常不寻常的。
使用额外的克隆可能不是简化测试的最佳方式。
第 1 步:创建本地克隆
由于您提到您正在使用 GitHub，如果您还没有本地克隆，则需要执行此步骤。
git clone <url-to-repo>
这将克隆您的存储库并自动 checkout master 分支，假设 master 分支是您在 GitHub 上设置的默认分支。
第 2 步:为您需要的每个分支创建一个克隆
如果您有 N 个额外的分支想要单独 checkout ，那么您可以通过重复以下操作为每个分支制作另一个克隆:
git clone <path-to-first-local-clone>
git checkout <branch>
请注意，每个克隆最终将至少使用与原始文件一样多的驱动器空间。可以通过为 git clone 使用 --shared 或 --reference 选项来减少使用的空间，但我没有足够了解这些选项的工作原理。
文档
关于git - 如何维护 TFS 中可用的 git 物理分支文件夹？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23210283/