Subversion 功能分支需要来自另一个功能分支的更改
我有两个功能分支：featureA 和 featureB。
FeatureA 已完成，但尚未合并到主干中，因为它未经测试，我们还没有准备好测试它。
我正在开发功能 B，并意识到需要在功能 A 中实施更改才能继续。
最好的方法是什么？我想我有几个选择：
选项 1
将 featureA 合并到 featureB 分支（或者如果我小心地获得我想要的所有分支，则可能只是特定的修订），然后恢复除我需要的更改之外的所有更改。
选项2
重新实现featureB中的更改（这次并不太复杂）并解决featureA和featureB合并到同一位置时的冲突。
无论哪种方式，这些功能都将合并到候选版本分支中，准备进行测试和部署。一旦该 RC 分支被确认通过测试，就会一次性合并到 trunk 中。
I have two feature branches: featureA and featureB.
FeatureA is complete, but not merged into trunk because it's untested and we're not ready to test it yet.
I'm working on featureB, and have realised that a change implemented in featureA is required for me to continue.
What's the best approach? I think I have a couple of options:
Option 1
Merge featureA to featureB branch (or maybe just specific revisions if I'm careful to get all the ones I want), then revert all but the changes I need.
Option 2
Re-implement the changes in featureB (they're not too complex this time) and sort out the conflicts when featureA and featureB are merged into the same place.
Either way, the features will be merged into a release candidate branch ready for testing and deployment. Once that RC branch is confirmed as tested, it'll be merged into trunk in one go.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
还有第三种选择：
您可以挑选要合并的内容，然后将其合并。执行从功能 A 到功能 B 的合并，但仅合并您感兴趣的修订。然后可以选择修复任何剩余问题。
例如，在 Eclipse 中，这可以非常方便地完成，因为合并对话框将让您选择要合并的修订版（或范围）。只需对您需要的所有修订范围重复此操作即可。
There's a third option:
You can cherry-pick what you want to merge, and merge just that. Perform a merge from featureA to featureB, but only merge the revisions that you are interested in. Then optionally fix any remaining problems.
In Eclipse e.g. this can be done quite conveniently, because the merge dialog will let you select which revision (or which range) you want to merge. Just repeat that for all the revision ranges you need.
我通过在 svn 中采用以下结构来解决此类问题：
开发人员在他们的沙箱中进行开发，然后在添加功能时合并到主干中。一旦迭代的功能顺利完成并准备好进行最终质量检查，主干就会被复制到登台。
因此，在您的场景中，功能 A 可以合并到主干，然后复制到沙箱以进行功能 B 开发。
I tackle these kinds of problems by having the following structure in svn:
Developers develop in their sandbox and then merge into trunk as features are added. Once a iteration's features are airly complete and ready for final QA, trunk is copied to staging.
So in your scenario, Feature A could be merged to trunk, then copied to sandbox for feature b development.
好吧，如果这两个功能不涉及对相同源文件的更改，那么在继续开发的同时将它们分开的最简单方法是创建一个混合工作副本。查看 featureB，然后根据需要将各个源文件切换到 featureA。 （如果您需要更多信息，请查找 svn switch。）您可以继续在 featureB 中进行更改并签入它们，而无需实际合并任何 featureA 代码。 （这将允许本地开发，但如果您使用持续集成，则会破坏服务器上的构建，因为必要的 featureA 更改不会出现。）
当然，如果 B 依赖于 A，则意味着 A 最终需要在 B 完成之前进行测试并准备发布。对我来说，这意味着您现在应该将 featureA 更改合并到 featureB 中，并在 featureB 上启动开发。您只需要确保当任何修复应用于功能 A 时，它们都会合并到功能 B 中。
Well, if the two features don't involve changes to the same source files, the easiest way to keep them separate while continuing development would be to create a mixed working copy. Check out featureB, and just switch individual source files to featureA as necessary. (Look up
svn switchif you need more info.) You could continue to make changes in featureB and check them in without actually merging any of the featureA code. (This would allow for local development, but would break the build on the server if you're using continuous integration because the necessary featureA change wouldn't be present.)Of course, if B depends on A, that means A will eventually need to be tested and ready for release before B can be completed. To me, that means you should merge featureA changes into featureB now and start dev on featureB. You'll just need to make sure that as any fixes are applied to featureA that they're merged into featureB.