我对 TFS 和源代码控制很陌生。我无法理解分支的优势。因为我可以通过创建 2 个文件夹 main 和 development 来做同样的事情，所以当我完成 development.I 可以使用任何 diff 工具将代码与主分支合并。
那么有分支有什么意义呢？我知道一定有巨大的优势，但我无法理解。
最佳答案
(更新:TFS 现在支持 git 进行版本控制，因此此答案的其余部分不再适用)
我会谷歌每个功能的分支。
分支的主要优点是您可以处理一个功能，而不会被其他人的工作打断。准备好后，您可以合并并查看许多功能是否可以很好地协同工作。这通常在功能开发时完成，但对于小功能，可以在功能完成后完成。
优点是您可以清楚地了解为实现某事所做的工作。如果没有分支，您将有大量提交与其他功能的提交混合在一起。如果 QA 没有通过某个功能，您的工作就会被裁掉，以便您仅使用其他功能的提交来组合另一个构建。另一种选择是尝试修复您的功能，以便 QA 通过。这在周五下午可能不可行。
功能切换是另一种省略工作的方法，但这会增加代码的复杂性，并且切换本身可能存在错误。这是非常令人厌烦的事情，看看这如何成为“可接受的”解决方法。
分支还用于跟踪对多个版本发布的更改。被多个客户消费的产品可能处于这样一种情况:一组客户正在使用产品的 1.0，而其他客户已经在使用 2.0。如果两者都支持，则应通过指定给它们的分支跟踪每个更改。前面的几点仍然适用于这些分支的开发。
话虽如此，出于多种原因，TFS 在每个功能的分支上并不理想。最大的是它不支持 3 路合并 - 它只有所谓的 baseless 合并。跟踪历史的方式，TFS 无法向您显示功能分支与您尝试将其合并到的位置之间的共同祖先。这让您有可能解决很多冲突。通常，出于这个原因，很多使用 TFS 的人都回避分支。
三路合并很棒，因为它们会向您展示共同的祖先是什么，您的更改是什么以及另一个分支中的更改是什么。这将使您能够就如何解决冲突做出非常有根据的决定。
如果您必须使用 TFS，我建议您使用 git-tfs 来利用 3 路合并和许多其他功能。其中一些包括:rerere、rebase、disconnected model、local history、bisect 等等。
Rebase 非常有用，因为它允许您更改基于另一个起点的功能、省略提交、将提交压缩在一起、拆分提交等。一旦准备就绪，您可以将它们合并到集成或发布分支中，具体取决于工作流程你决定。
Mercurial 也是另一种可能更易于使用，但从长远来看不会那么强大。
如果您有机会，我强烈建议您放弃 TFS 进行源代码控制，因为与现代 DVCS 相比有很多限制。
如果您想有效地管理分支/合并，请遵循以下一组很好的准则:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
希望这可以帮助。
关于TFS分支，有什么好处，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6208930/