将源代码管理中的更改提交到多个分支的实用方法
使用源代码控制时的常见场景是拥有开发分支和版本化发布分支。 我们使用 CVS，以 HEAD 作为开发分支，并为产品的当前版本创建一个名为例如 release-6-2 的分支。
新功能的开发仅进入开发分支，但错误修复有时必须同时检查到开发分支和当前发布分支。 有时这会变得非常乏味，所以我正在寻找实用的方法来实现这一点。
当要提交的文件在两个分支上同步时，我特别寻找快速“提交到这些分支”的解决方案。
（我们使用 CVS 作为我们的源代码控制系统，因此任何特定于 CVS 的答案都很好。但是，看看其他源代码控制系统是否可以提供更好的方法也很有趣。 在客户端我们使用Eclipse，所以Eclipse解决方案很好。 但如果您有非 Eclipse 解决方案，那也没关系。）
A common scenario when using source control is to have a development branch along with versioned release branches. We use CVS, with HEAD as the development branch, and a branch named e.g. release-6-2 for the current release of a product.
Development of new features go into the development branch only, but bug fixes sometimes have to be checked into both the development branch and the current release branch. This can get quite tedious at times, so I am looking for practical ways to accomplish this.
When a file to be commited is in synch on the two branches, I am in particular looking for a quick "commit to these branches" solution.
(We use CVS as our source control system, so any CVS-specific answers are nice. However, it is also interesting to see whether other source control systems can offer a better way.
On the client side we use Eclipse, so Eclipse solutions are good. But if you have a non-Eclipse solution, that is fine too.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将您的修复应用到所需的最旧的版本分支。 然后将更改合并到下一个发布分支，依此类推，直到从最后一个发布分支合并到 HEAD。
假设您产品的最旧版本是 1.0，并且您还有 1.1 和 1.5 版本。 下一版本的新功能将添加到 HEAD 中。 如果在 1.0 中发现错误，则将修复应用到 1.0 分支。 从 1.0 分支合并到 1.1 分支。 从1.1合并到1.5分支，最后从1.5分支合并到HEAD。
从一个分支合并到另一个分支比手动将修复应用到每个分支更好。
使用 CVS，您必须手动跟踪合并的版本，以便在下次合并时不会包含相同的修订版本。
如果您更改为使用 Subversion，则分支之间的合并会更容易。 Eclipse 的 subversion 工具将跟踪您之前合并的修订版本，从而大大简化了在两个分支之间进行重复合并的任务。
从 CVS 更改为 Subversion 很容易。 你不会是第一个采取这种行动的人。
Apply your fix to the oldest release branch required. Then merge the change to the next release branch and so on until you merge from the last release branch to the HEAD.
Say the oldest version of your product is 1.0 and you also have 1.1 and 1.5 releases. New features for the next release are being added to the HEAD. If a bug is found in 1.0, you apply the fix to the 1.0 branch. Merge from 1.0 to the 1.1 branch. Merge from 1.1 to the 1.5 branch, and finally merge from the 1.5 branch to the HEAD.
Merging from branch to branch is better than applying the fix manually to each branch.
With CVS you have to mannually keep track of what versions are merged, so that you do not include the same revisions when you do your next merge.
If you change to use Subversion, merging from branch to branch is easier. Eclipse's subversion tool will keep track of what revisions you have previously merged, greatly simplifying the task of doing repeated merges between two branches.
Changing to Subversion from CVS is easy(ish). You won't be the first to have made such a move.
就像 awalshe 所说，最好在分支之间合并。 要选择合并，请使用 实用版本控制 中描述的方法使用 CVS 非常好：
在分支 - 更改之前标记 (
PRE_FOO)，进行更改并提交，在更改之后标记 (POST_FOO)。 然后，在主干中，使用标签进行合并：在 SVN 中，分支之间的合并更加容易和安全，并且将整个 CVS 历史记录转换为 SVN 也很简单 - 请参阅 cvs2svn。 您应该使用 SVN 1.5，或者 - 对于早期的 SVN 版本 - svnmerge。
Like awalshe said, it's better to merge between branches. To cherry-pick a merge, the method described in Pragmatic Version Control using CVS is very good:
In the branch - tag (
PRE_FOO) before the change, make the changes and commit, tag after the change (POST_FOO). Then, in trunk, merge using the tags:Merging between branches is much easier and safer in SVN, and it's trivial to convert your entire CVS history to SVN - see cvs2svn. You should use either SVN 1.5, or - with earlier SVN versions - svnmerge.