提交与合并
我们必须为我们的产品创建一个特殊的临时 alpha 版本，该版本应仅包含一组选定的功能。我们的主要版本的 trunk 中也需要这组功能。
我的感觉是从主干分支进行临时发布，并频繁地将稳定分支合并到主干，以便我们保持同步。然而，还有第二种思想，我们致力于这两个地方，并最终合并分支。
- 我认为第二种方法中存在一些问题。由于我们会在两个地方进行更改，因此合并稍后会产生问题。 （对于任何错过的提交）
- 提交产生的任何错误也会破坏主干的稳定性。如果我们合并稳定的分支，就可以避免这种情况。
- 开发人员将其提交到主干的开销。 （需要工作副本，需要第二次提交）
我的问题是，你能让我了解这两种方法的更多优点和缺点吗？
We have to create a special interim alpha release for our product which should consist of only a select set of features. This set of features are also required in trunk for our main release.
My feel is branch from trunk for the interim release and to make frequent merges of the stable branch to trunk so that we are in sync. However there is a second school of thought that we commit into both places and also merge the branch finally.
- Here are couple of things which I feel would be problematic in the second approach. As we would have the changes in both places, merge would create problems later on. (for any missed commits)
- Any bugs created by the commits would destabilize trunk too. This can be avoided if we merge stable branches.
- Overhead for the developer to commit it in to trunk too. (need a working copy, need a second commit)
My question is, can you let me know more positives and negatives of both these approaches ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
很多人称之为“功能分支”。您可以从主干中分离出来，在新分支中实现一堆新东西，然后在完成后将其合并回主干。如果你使用 svn 或任何现代的东西，合并能力是相当稳定的。这意味着您可以从主干中发布不包含此新代码的其他版本，直到您完成为止。
我更喜欢只进行一次主提交，并在需要时将其合并到其他分支。我认为这使得代码库更加干净。
如果您需要更早地进行新分支的更改，您始终可以在各个点进行临时合并，例如在 QA 测试新功能之后。这样您就可以控制两个分支的稳定性。
A lot of people call this a "feature branch". You can split off of trunk, implement a bunch of new stuff in your new branch, then merge it back to trunk when you are done. If you are using svn or anything modern, the merge abilities are pretty stable. This means you can make other releases from trunk that do not contain this new code until you are finished with it.
I prefer to make a primary commit only once, and merge it to other branches when needed. I think this makes for a much cleaner codebase.
If you need the new branch's changes earlier, you can always do interim merges at various points, such as after a new feature is tested by QA. This way you can control how stable both branches are.
因为我还没有收到这两种方法的任何重要推理。我正在回答我自己的问题。我会根据我的问题本身所述的好处采用合并方法。
As I have not received any significant reasoning for both the approaches. I am answering my own question. I would go with the merge approach as per the benefits stated in my question itself.