我们在发布周期中维护多个TFS分支。当前流程是在完成用户故事时，将WIP分支中的变更集挑选到测试分支中。
我很想知道git-tf是否允许以这种方式使用多个远程分支，并且它是否能够检入合并而不是检查看起来像新代码的代码。
这里有一个关于此的讨论：
Merge two TFS branches with git tfs
并且有人提到git-tfs对于那些直接使用VS的人来说不会很好。有谁知道git-tf是否就是这种情况？
答案 0 :(得分：5)
此时，git-tf不代表具有git分支的TFS分支，并且不会在任何方向上转换合并 - 也就是说它不会检入合并，也不会显示结果TFS合并为git合并。这是一个非常重要的问题，因为两种架构中的合并之间存在一些非常根本的差异。
TFS合并为git merges：
在git中，您合并两个提交，最后得到一个结果提交。 TFS看起来很相似 - 因为您选择了合并源和目标变更集，但合并源不必是变更集。您可以根据标签，工作区版本，日期等进行合并。这意味着您最终可以最终合并来自多个不同更改的不同文件。这是一个容易解决的问题（最终，我认为，将其表示为一些疯狂的章鱼合并）。
要解决的难题是根据TFS分支创建git分支。这更像是一个设置问题 - 即你想要哪些分支？他们都是？他们中有一些？如果答案是“所有这些”，那么在进行初始克隆时很容易设置。但对我来说，这是第一次设置的数百个分支机构，而且价格昂贵。如果答案是“其中一些”，那么当你做克隆时你必须全部指定它们，否则你最后会以恶劣的方式重写git历史。
git合并为TFS合并：
在git中，分支是一种短暂的。它实际上只是一个指向树中节点的指针...没有长期存在的状态说“提交1b4caf曾经在分支branch中。”想象一下，你有一些指向TFS分支master的git分支$/Proj/main和指向test的另一个git分支$/Proj/test。在git中，您将test合并到main。没问题，此时main的{{1}}提交的父级是HEAD的{{1}}。但是如果你开始改变test分支中的内容，很快就很难确定。
此外，现在HEAD将单个git分支映射到您的TFS服务器路径。对于合并签到，我们必须立即检查多个分支。假设您对test做了一些提交，并对git-tf做了一些提交，然后合并了每个master。现在我们必须检查每个TFS分支的几个提交，然后进行合并。这不一定很难，但它与test目前的工作方式完全不同。
这绝不是一个不可能的问题，但需要一些聪明的工程和一些巧妙的测试。但它还没有。