我在一家“内部”IT 商店，我们目前使用 ClearCase 进行版本管理。我们的分支策略很常见，主分支保留用于实时代码，而主分支则用于项目和修补程序类型的活动。每个项目（它们经常重叠）都有一个主分支，我们没有多层分支。
我们得到的情况是，我们必须在集成分支之间进行合并，以便版本 4 分支在版本 3 上线之前获取所有版本 3 的更改（例如），从而成为基线。以及当项目很高且必须支持时发生修补程序的次数。
然而，这在 TFS 世界中实际上是不可能的，因为我们不希望不得不进入命令行来进行毫无根据的合并，但是我们需要具有高度灵活的分支能力——我们已经真正拥有了习惯于使用 ClearCase。
因此，理想情况下，我们希望 TFS 分支允许我们拥有生产基线，能够分支执行短期修补程序，能够分支执行项目——实际上并不知道哪些分支将上线（因此基线）首先。通过所有的 MS 文档，他们似乎都专注于产品类型环境 - 但我们主要是一家支持和增强商店。
我正在寻找建议/指针——我一直是 ClearCase 管理员，可以很高兴地在心理上处理分支——但我想出的所有东西看起来都不适合 TFS——但这很可能是因为我的心理过程类似于 ClearCase，并且与 TFS 不一致（还没有！）
