哪个版本控制支持多个版本的合并？
想象一下您有一个大型软件项目，您必须同时支持多个分支（版本）。 例如，您在网站上有一个生产版本、当前由客户测试的集成测试版本、用于本地系统测试的测试版本以及开发人员正在开发新功能的开发版本。
什么版本控制系统很好地支持这种设置？ 我主要关心的是它应该支持不同版本之间的合并 - 如果您修复了生产版本中的紧急错误，您不想同时检查所有其他版本并手动修复该错误 5 次。
如果你有答案，我想听听你应用它的项目有多大，以及你有什么经验。 我正在寻找一个明确支持的系统 由开发人员合并 - 解决方案与应用的脚本 构建经理等不会帮助我们。 （太危险了；应该进行合并 开发人员立即由他/她知道该怎么做。） 非常感谢！
Imagine you have a large software project where you have to support several branches (releases) at the same time. For instance you have a production release on the website, a integration test release that is currently tested by the customer, a testing release that for your local systems test and a development release where your developers are hacking away new features.
What version control system supports this setup well? My main concern is that it should support merging between the different releases - if you fix an urgent bug in your production release you do not want to check out all other releases as well and fix the bug by hand 5 times.
If you have an answer I would like to hear how big the project you applied it in was and what experiences you had. I am looking for a system that explicitly supports
merging by the developer - solutions with scripts applied by
build managers etc. won't help us. (Too dangerous; the merge should be done
by the developer immediately since he/she knows best what to do.)
Thanks so much!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我认为大多数（如果不是全部）现代 SCM 都可以做到这一点。 不一定是自动的，尽管有些脚本可以以相当轻松的方式处理它。
在工作中，我们使用 Perforce，并手动进行集成（在 Perl 脚本的帮助下复制更改列表信息）。 我们仔细选择要发布的变更列表（例如，我们可以丢弃有风险的变更列表）。
对于大多数分布式 VCS（Mercurial、Bazaar，可能还有 Git 等）来说，使用多个分支（或克隆）是自然的工作流程。
I think most, if not all, modern SCMs can do that. Not necessarily automatically, although some scripts can handle that in a quite painless way.
At work, we use Perforce, and we do the integrations by hand (helped by a Perl script to copy changelist information). We carefully choose which changelists go to release (we can discard risky ones, for example).
For most distributed VCS (Mercurial, Bazaar, probably Git, etc.), working with several branches (or clones) is the natural workflow.
根据我的经验，与颠覆合并是可行的，但相当痛苦（尽管我听说新版本在这方面更好）。 Git 和 Mercurial 确实可以正确合并，没有任何问题。
In my experience merging with subversion works, but is quite painful (though I've heard newer versions are better in this respect). Git and Mercurial do merges properly with no problems.
Team Foundation Server 支持任意数量的分支和合并。 它本身就相当不错，但 2010 版本的功能使分支更加引人注目。 请参阅10- 4 第 4 集：不再有并行开发的痛苦。
Team Foundation Server supports any number of branches, with merging. It's pretty good as it is, but the features of the 2010 release make branching even more compelling. See 10-4 Episode 4: No More Parallel Development Pain.
Clearcase 将处理多个分支和修订，以及任何/全部之间的合并这些。 您可以随意定义分支，根据需要进行标记，并与这些分支合并或从这些分支合并。 不用说，这可能会变得异常复杂，IBM 提供了一个合并管理器来帮助您。 您可以以图形方式显示分支（如果有帮助）。
Clearcase 功能非常强大，但管理起来也相应复杂且耗时。
Clearcase will handle multiple branches and revisions, and merging between any/all of these. You can define branches at will, labelled as you desire, and merge to/from these. Needless to say, this can get extraordinarily complicated and IBM provides a merge manager to help you. You can display the branches graphically (if that helps).
Clearcase is amazingly powerful, but correspondingly complex and time-consuming to manage.
如果您确实想处理多个版本但又不想遭受 Clearcase 的痛苦，您应该尝试类似 Accurev 或 PlasticSCM。
Accurev 在处理流方面非常强大，你必须习惯它们，但一旦你习惯了，它就会非常非常强大。
塑料在处理无限数量的分支（及其相应的合并）方面更强大，说起来容易做起来难。 您拥有 Good-ol CC 提到的所有灵活性，但没有晦涩的命令或奇怪的配置。
这里有分支资源管理器跟踪多个分支
If you really want to handle multiple releases but not suffering the pain of Clearcase you should try something like Accurev or PlasticSCM.
Accurev is very powerful dealing with its streams, you've to get used to them but once you do it's very, very powerful.
Plastic is more powerful in terms of handling unlimited number of branches (and their corresponding merges) something easier said than done. You've all the flexibility mentioned for good-ol CC but without the arcane commands or weird configurations.
Here you've the branch explorer tracking multiple branches
这个问题的答案是流程第一，工具链第二。
您需要决定如何访问已知版本（例如“正在生产什么？”）、如何对这些版本进行更改以及如何将更改传播到其他版本。
大多数 Subversion-Or-Better 的 VCS 系统都支持常见的工作流程。 以下是常见的一种：
这是另一种常见的做法：
这些都是非常常见且易于实现/理解的； 大多数版本控制系统都很容易支持它们。 如果您获得更复杂的流程，您将减少可用的工具集，但可能拥有更多功能。
The answer to this question is one of process first, and toolchain second.
You need to decide how you wish to access known versions (e.g. "what's on production?"), how you want to make changes to those and how you want to disseminate changes to other versions.
Most VCS systems that are Subversion-Or-Better will support common workflows. Here is one that is common:
Here is another common practice:
These are very common and simple to implement/understand; they are easily supported by most version control systems. If you get more complex processes, you will reduce the toolset available, but possibly have more power.
可以配置 Telelogic CM Synergy/CM 以支持此类设置。
优点是，如果文件在这些版本中未更改，所有“更高”版本都会自动更新，无需开发人员或构建管理员执行操作。 如果修改的文件发生更改，开发人员会在签入时立即收到通知，并且必须合并这些内容。 它支持将相关变更分组为任务和变更请求，并具有相关的跟踪系统。
缺点是它确实又大又慢，需要大量的 buildmanager 时间，而且 eclipse 集成几乎无法使用。 您可能需要每 5 名或 10 名开发人员配备一名全职构建经理。
It is possible to configure Telelogic CM Synergy/CM to support such a setup.
The good point is that all "higher" releases are updated automatically without developer or build manager actions if the file is unchanged in those releases. If the modified file is changed, the developer is notified immediately on checkin and has to merge the stuff. It supports grouping of related changes into tasks and change requests and has an associated tracking system for those.
The bad points are that it is really big and slow, needs a lot of buildmanager time and the eclipse integration is almost unusable. You'll probably need a fulltime buildmanager each 5 or 10 developers.