如何同时使用 1.1 版和 2.0 版？
情况：我们的测试版已经结束，1.0 版已发布到多个客户站点。 A 团队已经忙于开发 1.1 版本，该版本将进行增量错误修复和可用性调整，而另一个团队则致力于进行大规模更改的 2.0 版本，其中产品的核心可能已完全重新设计。 现在，对 1.1 所做的大部分更改都必须在某个时候进入 2.0，并且 2.0 分支中所做的一些错误修复实际上可能需要安排在早期版本中。 问题是，由于 2.0 存在根本差异，因此如果不进行手动转换，就无法合并 1.1 中的任何更改，反之亦然。
我的问题：在这种情况下，最大限度地减少合并冲突和重复工作的最佳修订控制实践是什么？ 如何确保我的团队在版本控制问题上花费尽可能少的时间和精力，同时仍然向客户提供定期补丁？
The situation: We're out of beta and version 1.0 has been released to several customer sites. Team A is already busy working on version 1.1 that will have incremental bugfixes and usability tweaks, while another team works on version 2.0 with large-scale changes, where the core of the product may have been completely redesigned. Now, most of the changes made for 1.1 will have to make their way into 2.0 at some point, and some of the bug fixes made in the 2.0 branch might in fact need to be scheduled for an earlier release. The problem is that since 2.0 has fundamental differences, no changes from 1.1 can be merged in without manual conversion, nor vice versa.
My question: What are the best revision control practises to minimise merge conflicts and duplicate work in this kind of situation? How can I ensure that my teams spend as little time and effort as possible on revision control issues, while still providing regular patches to customers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
其他人都说了，但我想我会扔掉我使用 SVN 处理多个分支开发的经验
对于我们的主要产品，我们需要同时在 2 个以上版本中同时开发。
我最初使用主干作为“主要开发”版本，每个实际版本都使用标签。 分支用于新功能集的大量开发工作。 后来，当我们开始同时开发 2、3 和 4 个版本时，我开始为每个版本使用一个分支。
由于我维护存储库并处理推送 QA 构建，因此我确保每天早上进行“汇总”，其中包括从当前最低活动分支开始合并树上的更改。 因此，我最终将 1.1 的更改合并到 1.2 中，然后将其与上次合并以来 1.2 中的任何其他更改合并到 1.3 中。
当我提交时，我确保始终使用类似的内容来评论提交
这可能有点痛苦，但它有效:)
Pretty much what everyone else has said, but I figured I would toss in my experience with handling development in multiple branches using SVN
With our main product, we have the need to simultaneously develop in 2+ versions at the same time.
I originally used the main trunk as the "main development" version, with tags used for each actual release. Branches were used for substantial development efforts for a new feature set. Then later, when we started working on 2, 3 and 4 releases at a time I started using a branch for each revision.
Since I maintain the repository and also handle pushing QA builds, I make sure to do "rollups" each morning - which consists of merging changes up the tree starting with the lowest currently active branch. So I end up merging changes from 1.1 into 1.2, which is merged into 1.3 with any other changes from 1.2 since the last merge, etc.
When I commit, I make sure to always comment the commit with something like
It can be a bit of a pain, but it works :)
为此，我可能会依赖问题跟踪系统，并确保标记需要提交到主干代码中的每个更改。 然后，您可以确保每个更改的签入注释都引用了相关问题，并且清楚地表达了代码更改的意图，以便在尝试在主干中重新实现时可以轻松理解。
I would probably rely on an issue tracking system for this purpose, and make sure to tag each change that needed to be brought forward into the trunk code. You can then ensure that check-in comments for each change reference the relevant issue, and are clear in expressing the intent of the code change so that it can be easily understood when trying to re-implement in the trunk.
文章此处（Subversion 的日常）提到一种方法是使用版本 1.1 构建中的数据不断更新版本 2。 在文章中，那家伙说每天都要这样做。
您想要阅读的部分标题为“服务员，我的后备箱里有一个错误！”。 文章已经写到一半了。
The article here (Day-to-day with Subversion) mentions that one method is to constantly update version 2 with data from the version 1.1 build. In the article, the guy says to do this every day.
The part you'll want to read is titled "Waiter, There's a Bug in my Trunk!". It's about halfway though the article.
一种好的方法是修复稳定分支中的每个错误并将稳定分支合并到开发分支中。 这是并行维护/开发线模式，关键是尽早并经常合并。 合并不频繁且较晚意味着开发分支与稳定分支相比无法识别，或者错误无法以相同的方式重复。
Subversion 自版本 1.5 起就包含合并跟踪，因此您可以确保相同的更改集不会合并两次，从而导致愚蠢的冲突。 存在其他系统（例如 Git、Mercurial、Accurev、Perforce），让您可以进行“分支 A 上的哪些更改尚未合并到分支 B 中？”类型的查询。 并挑选您需要的修复程序到开发分支。
One good way is to fix each bug in the stable branch and merge the stable branch into the development branch. This is the Parallel Maintenance/Development Lines pattern, and the key is to merge early and often. Merging infrequently and late means that the development branch is unrecognisable compared to the stable one, or the bug cannot be repeated in the same way.
Subversion includes merge tracking since version 1.5 so you ensure that the same change set is not merged twice, causing silly conflicts. Other systems exist (e.g. Git, Mercurial, Accurev, Perforce) that let you make queries of the type "what changes on branch A have not been merged into branch B?" and cherry-pick the fixes you need across to the dev branch.
尽早合并，经常合并，并确保主线上的 QA 了解并回归/验证维护版本的每个补丁中修复的缺陷。
让某些东西溜走并在后续版本中“修复”错误确实很容易，让我告诉你，客户并不关心管理多个分支会变得多么复杂——那是你的工作。
确保您使用的源代码控制系统支持分支和合并（我有使用 Perforce 和 SVN 的经验，虽然 Perforce 更好，但 SVN 是免费的）。
我还相信，由一个人负责以一致的方式执行合并有助于确保合并定期发生。 通常是我或我们团队中的一位资深人员。
Merge early, merge often, and make sure that QA on the mainline knows and regresses/verifies the defects fixed in each patch of the maintenance releases.
It's really easy to let something slip out and "unfix" a bug in a subsequent release, and let me tell you, customers don't care about how complicated it can get to manage multiple branches -- that's your job.
Make sure you're using a source control system that supports branching and merging (I've had experience with Perforce and SVN, and while Perforce is better, SVN is free).
I also believe that having a single person responsible for performing the merges in a consistent manner helps ensure that they happen regularly. It's generally been me or one of the senior people on our team.
我们在工作中处理这个问题的方法是保持主干分支作为最前沿的代码（即本例中的2.0）。 您为 1.x 代码创建一个分支，并在那里进行所有修复。 对 1.x 的任何更改都应合并（如果需要，手动）到主干 (2.0) 分支。
然后，我会坚持要求 1.x 开发人员在该错误的票证中记下 1.x 提交的修订号和 2.0 合并的修订号。 这样，如果有人忘记合并他们的更改，就会更容易注意到，而他们必须跟踪它的事实将帮助他们记住。
The way we handle this at my work is to keep the trunk branch as the most cutting-edge code (ie, 2.0 in this case). You create a branch for the 1.x code, and make all your fixes there. Any changes to 1.x should be merged (manually, if need be) into the trunk (2.0) branch.
I would then insist that 1.x developers make note of both the revision number for the 1.x commit and the revision number for the 2.0 merge in the ticket for that bug. That way, it will be easier to notice if anyone forgets to merge their changes, and the fact that they have to keep track of it will help them remember.
为了回答这个具体问题，许多开发人员已经从 Subversion 转向 Git。 查看 github.com。
To answer that specific question many developers have switched from Subversion to Git. Checkout github.com.
这张图片来自 The Build Doctor：仅合并一个方向。
One key point is captured in this picture from The Build Doctor: only merge one direction.