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