（更新：TFS 现在支持 git 进行版本控制，因此本答案的其余部分不再适用）
我会按功能搜索分支。
分支的主要优点是您可以处理某个功能而不会被其他人的工作打断。准备好后，您可以合并并查看许多功能是否可以很好地协同工作。这通常在功能开发时完成，但对于小功能，可以在功能完成后完成。
优点是您对实施某件事所做的事情有清晰的历史记录。如果没有分支，您将有大量提交与其他功能的提交混合在一起。如果 QA 未通过某个功能，您就需要完成工作，仅使用其他功能的提交来组合另一个版本。另一种选择是尝试修复您的功能，以便 QA 通过。这在周五下午可能无法实现。
功能切换是省略工作的另一种方式，但这会增加代码的复杂性，并且切换本身可能存在错误。这是令人非常厌倦的事情，看看它如何成为一个“可接受的”解决方法。
分支还用于跟踪多个版本的更改。由多个客户消费的产品可能会出现这样的情况：一组客户正在使用该产品的 1.0，而其他客户已经在使用该产品的 2.0。如果您同时支持两者，则应该通过指定给它们的分支来跟踪对它们的更改。前面的几点仍然适用于这些分支的开发。
话虽如此，出于多种原因，TFS 在按功能分支方面并不理想。最大的问题是它不支持三向合并——它只有所谓的无基础合并。根据跟踪历史记录的方式，TFS 无法向您显示功能分支与您尝试将其合并到的位置之间的共同祖先。这使您有可能解决很多冲突。一般来说，很多使用 TFS 的人都因为这个原因回避分支。
三向合并很棒，因为它们会向您展示共同祖先是什么、您的更改是什么以及另一个分支中的更改是什么。这将使您能够就如何解决冲突做出明智的决定。
如果您必须使用 TFS，我建议使用 git-tfs 以便能够利用 3 路合并和许多其他功能。其中包括：rerere、rebasing、断开连接的模型、本地历史、bisect 等等。
Rebase 非常有用，因为它允许您更改基于另一个起点的功能、省略提交、将提交压缩在一起、拆分提交等。准备好后，您可以将它们合并到集成或发布分支中，具体取决于工作流程你决定。
Mercurial 也是另一种可能更容易使用的工具，但从长远来看不会那么强大。
如果您有机会，我强烈建议您放弃使用 TFS 进行源代码控制，因为与现代 DVCS 相比存在很多限制。
如果您想有效地管理分支/合并，可以遵循以下一组很好的准则：
http://dymitruk.com/blog/2012/02/05/branch-per-feature/ http://dymitruk.com/blog/2012/02/05/branch-per-feature/
希望这可以帮助。
