我的任务是研究如何改进我公司处理版本控制的方式。
目前我们使用Borland StarTeam，它有一些问题。除了经常难以使用之外，支持它的工具数量（IDE支持，代码审查......）非常低。
我们公司有40个开发人员，但我们合作了很多不同的项目。给定项目通常有3-6个软件开发人员一起工作。 我们的项目范围从（主要）嵌入式系统和FPGA开发到桌面应用程序。
当前的工作流程集中了一个“视图”（它接近StarTeam语言中的分支），项目中的每个人都可以使用它。
其中一个项目以下列方式使用多个视图： 有一个没有开发的平台视图。然后，该视图具有两个子视图，用于两个共享大多数代码的特定产品（通过平台视图），但不同，可以分开。 所有开发都在两个产品视图中进行，有时产品视图中的代码将提升到平台视图（然后可以自动用于其他产品）。
当有一个主要功能添加时，另一个项目似乎使用主视图和功能视图。
我们通常需要长时间支持软件并提供软件更新。
我们的一些产品有很多不同的版本。不同的版本将共享大多数代码，但某些部分是并且必须有明显不同。
开发人员在他们的开发工作站上使用Windows和Linux。
我的想法是切换到使用现代DVCS。我正在考虑的工作流程是每个项目都有许多公共分支，每个开发人员都可以克隆和处理这些分支。然后，每个项目都可以确定每个人是否可以自由提交，或者我们是否应该拥有某种门户管理系统，其中代码需要通过人工或自动构建系统才能提交给公共分支。
我对分支设置的想法是使用版本和功能分支，如以下场景所示：
假设我们从开发开始，最后发布我们产品的1.0版本。然后我们发现我们需要更多功能，因此我们的目标是2.0发布并为此启动一个新的分支。在2.0版本分支上工作时，我们仍然可以在1.0分支上进行维护，从而导致版本1.1的发布，依此类推。
在处理2.0分支时，我们发现了一个已修复的安全问题。因为它在1.0分支中也是可用的，所以代码也被反向移植到1.0分支。
在2.0分支中的某个时候，发现系统的某些部分确实需要完全重做才能创建特征X.创建并处理了一个新的公共2.0特征-X分支。完成后，该分支中的工作将合并回主2.0分支。
希望你现在还在阅读：）
上述工作流程（发布和功能分支）是否可行？是否有坑坑洼地需要注意？
在产品具有平台分支和多个产品分支的情况下，处理此问题的最佳方法是什么？是否会创建一个主分支和产品分支？两个产品分支何时出现问题？他们有多大分歧？
我错过了什么吗？我主要从开发人员的角度看VCS，所以从配置或发布经理的角度来看，我可能会遗漏那些重要的东西。
答案 0 :(得分：0)
对于您的第二个问题，我认为您可以分享与不同产品共享的平台相关代码和“大多数代码”，并且仅支持使产品“不相似”的源代码。使用“共享”，如果在一个项目中修改了项目，则更改将同时反映在其他项目中。使用Branch，文件及其对应文件是独立的。
因此，两个产品分支可以根据需要分开。