TFS分支，有什么优点
我对 TFS 和源代码管理还很陌生。我无法理解分支的优势。因为我可以通过创建 2 个文件夹 main 和development 来完成相同的操作，所以当我完成开发时。我可以使用任何 diff 工具将代码与主分支合并。
那么设立分支机构还有什么意义呢？我知道一定有巨大的优势，但我无法理解。
I am pretty new to TFS and source control. I unable to understand the advantage of branching. Since i can do the same stuff by creating 2 folder main and development, when I am done with development.I can merge the code using any diff tool with the main branch.
Then whats the point of having branches ? I know there must a huge advantage but i am unable to understand.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
（更新：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/
希望这有帮助。
(UPDATE: TFS now supports git for version control so the rest of this answer no longer applies)
I would google branch-per-feature.
The main advantage of branching is that you can work on a feature and not be interrupted by anyone else's work. When you are ready, you can merge and see if many features work well together or not. This is usually done as the feature is developed but for small features can be done once the feature is complete.
The advantage is that you have a clear history of what you did to implement something. Without branches, you would have a whole lot of commits mixed together with other features' commits. If QA does not pass a certain feature, you have your work cut out for you to put together another build using just the commits for the other features. The other alternative is to try and fix your feature so that QA passes. This may not be doable on a Friday afternoon.
Feature toggles are another way to omit work but this increases the complexity of code and the toggles may themselves have bugs in them. This is something to be very weary of and see how this became an "acceptable" work-around.
Branches are also used to track changes to multiple versions of releases. Products that are consumed by multiple customers may be in a situation that one set of customers is using 1.0 of the product while others are already on 2.0. If you support both, you should track changes to each by branches that are designated to them. The previous points still apply to developing for these branches.
Having said that, TFS is not ideal at branch-per-feature for a number of reasons. The biggest is that it does not support 3-way merges - it only has what is called a baseless merge. The way history is tracked, TFS cannot show you a common ancestor between the feature branch and where you are trying to merge it to. This leaves you potentially solving a lot of conflicts. In general, a lot of people that use TFS shy away from branching for this reason.
3-way merges are great because they will show you what the common ancestor is, what your changes are and what the changes in the other branch are. This will allow you to make a very educated decision on how to resolve a conflict.
If you have to use TFS, I would suggest using git-tfs to be able to take advantage of 3-way merges and many other features. Some of them include: rerere, rebasing, disconnected model, local history, bisect, and many many more.
Rebase is very useful as it allows you to alter a feature to be based off of another starting point, omit commits, squash commits together, split commits, etc. Once ready you can them merge into an integration or release branch, depending on the workflow you decide upon.
Mercurial is also another one that may be easier to use, but will not be as powerful in the long run.
If you have the opportunity, I would highly recommend moving away from TFS for source control due to a lot of limitations when compared to modern day DVCS.
Here is a nice set of guidelines to follow if you want to effectively manage branching/merging:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
Hope this helps.
有很多信息需要阅读，但如果有帮助的话，这里有 TFS 分支指南 - http:// tfsbranchingguideiii.codeplex.com/
There is a lot of information to read through, but there is TFS Branching Guidance located here if it helps at all - http://tfsbranchingguideiii.codeplex.com/