我们的团队目前使用的是普通的旧式 TFS 2005，没有分支、共享结账等...我想介绍一个 DEV/MAIN/PROD 分支系统，类似于 TFS 指导文档，以便我们可以进行一些并行开发、隔离和巩固审查和部署流程。
我已经阅读了大部分白皮书等。你们有什么实用的建议、建议的工具、陷阱或推荐吗？另外，我们计划在它发布后迁移到 2010 年 - 不确定这是否会影响任何事情。我很感激我能得到的所有建议和帮助，因为我是一个分支新手。
Our team is currently using plain old TFS 2005, no branching, shared checkouts etc... I would like to introduce a DEV/MAIN/PROD branching system similar to the basic flavor in the TFS Guidance document so that we can do some parallel dev, isolation, and firm up review and deployment processes.
I have read most of the whitepapers etc. Do you guys have any practical advice, suggested tools, gotchas or recommendation. Also, we plan to migrate to 2010 once it comes out - not sure if that would affect anything. I appreciate all the suggestions and help I can get as I am a branching neophyte.
发布评论
评论（1）
我的建议是保持分支策略简单。人们很容易得意忘形并实施相当复杂的分支策略，而这些策略需要整个团队来管理。
我倾向于只使用一个“主分支”和一个（或多个）“发布分支”。主分支是进行日常开发的地方，发布分支用于在将代码推送到生产环境之前拍摄代码快照。
随着项目随着时间的推移而发展，主分支不断变化，而发布分支是一种返回对生产中的内容进行更改的方法，而不会冒包括主分支上其他正在进行的更改的风险。发布分支用于进行热修复。
我在我的博客上对此进行了更详细的描述：
http:// /hectorcorrea.com/Blog/Simple-Branching-Strategies-for-Team-Foundation-Server
My advise would be to keep your branching strategies simple. It's easy to get carried away and implement rather sophisticated branching strategies that require a whole team just to manage them.
I tend to go by with just a "main branch" and one (or many) "release branches". The main branch is where day to day development happens and the release branch is used to take a snapshot of the code before is pushed to production.
The main branch continues changing as the project evolves over time while the release branch is a way to go back to make a change to what's in production without risking including other on-going changes on the main branch. The release branch is used to make hot-fixes.
I've described this in more detail on my blog:
http://hectorcorrea.com/Blog/Simple-Branching-Strategies-for-Team-Foundation-Server