选择版本控制工作流程
我的任务是研究如何改进公司处理版本控制的方式。
背景
目前我们使用 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-feature-X 分支。完成后，该分支中的工作将合并回主 2.0 分支。
实际问题
希望此时您仍在阅读:)
上述工作流程（发布和功能分支）是一个可行的选择吗？是否有需要注意的陷阱？
在一个产品有一个平台分支和多个产品分支的场景中，最好的处理方法是什么？创建主分支和产品分支是否有效？当两个产品分支出现分歧时会出现问题吗？它们能相差多少？
我是不是错过了什么？我主要从开发人员的角度看待 VCS，因此从配置或发布经理的角度来看，我可能会遗漏一些重要的内容。
I have been tasked with researching how to improve the way my company handles version control.
Background
Currently we use Borland StarTeam, which has some issues. Apart from often being difficult to use, the number of tools (IDE support, code review, ...) which support it is very low.
Our company has something like 40 developers but we work with a lot of different projects. A given project usually has something like 3-6 software developers working together.
Our projects range from (mostly) embedded systems and FPGA development to desktop applications.
The current work flow is heavily centralized with one "view" (which is close to a branch in StarTeam language) that everyone in the project works on.
One of the projects use multiple views in the following way:
There is a platform view where no development is done. This view then has two sub views for two specific products that share most code (via the platform view) but is dissimilar enough to be kept apart.
All development is made in the two product views and sometimes code from a product view is promoted to the platform view (which is then automatically available for the other product).
Another project seems to use a main view and a feature view when there was a major feature addition.
We usually have to support software for a long time and provide software updates.
Some of our products have a large number of different versions. The different versions will share most code but some parts are and must be distinctively different.
Developers use both Windows and Linux on their development work stations.
Idea
My idea is to switch over to use a modern DVCS. The work flow I am considering is where each project has a number of public branches which each developer can clone and work on. Each project could then determine if everyone can commit freely, or if we should have some kind of gate keeper system where code needs to pass a human or automated build system before being committed to the public branch.
My idea on the branching setup is to use release and feature branches as in the following scenario:
Let's say we start with development and finally ship version 1.0 of our product. We then find that we want some more features so we aim for a 2.0 release and start a new branch for this. While working on the 2.0 release branch we can still do maintenance on the 1.0 branch leading to the release of version 1.1, and so on.
While working on the 2.0 branch we discover a security problem which is fixed. Since it is available in the 1.0 branch as well that code is backported to the 1.0 branch as well.
Sometime in the 2.0 branch it is discovered that some parts of the system really needs to be completely redone to be able to create feature X. A new public 2.0-feature-X branch is created and worked on. When done, the work in that branch is merged back into the main 2.0 branch.
Actual questions
Hopefully you are still reading at this point :)
Is the above work flow (release and feature branching) a viable option? Are there pit falls to look out for?
In the scenario where a product has a platform branch and multiple product branches, what is the best way to handle this? Would creating a master branch and the product branches work? Is there a problem when two product branches diverge? How much can they diverge?
Have I missed something? I mostly see VCS from a developer perspective so I might be missing stuff that is important from the perspective of a configuration or release manager.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于你的第二个问题，我认为你可以共享平台相关的代码和不同产品共享的“大多数代码”，并且只分支使产品“不相似”的源代码。通过共享，如果在一个项目中修改了一项，则所做的更改将同时反映在其他项目中。对于 Branch，文件及其副本是独立的。
因此，这两个产品分支可以根据您的需要进行差异化。
For your second question, I think you can SHARE the platform related code and "most code" shared by different products, and only BRANCH the source code which makes the products "dissimilar". With Share, if an item is modified in one project, the changes will be reflected in other projects simultaneously. With Branch, the file and its counterparts are independent.
So, the two product branches can be diverged as much as you need.