0

我是一名开发人员，正在学习如何使用源代码控制软件。我已阅读Subversion 文档。我理解合并的概念，但我的问题是：你多久合并一次？

例如，如果您有一个开发人员在主干上工作，而两个开发人员在不同的分支上工作，那么他们什么时候：

1) Merge the trunk with branch 1
2) Merge the trunk with branch 2
3) Merge branch 1 with the trunk
4) Merge branch 1 with branch 2
5) Merge branch 2 with the trunk
6) Merge branch 2 with branch 1

在此示例中，请假设三个更改是相互独立的。你每天结束时都合并吗？- 假设更改当然是稳定的，或者您是否在发布日期前及时合并？

过去（当我没有使用源代码控制时）我已经发布了。我认为最好设置一个我（和其他开发人员）可以努力的发布日期？

我今天准备了很多关于合并和分支的帖子，例如：TortoiseSVN 的好分支和合并教程？. 我还没有找到我的具体问题的答案。

4

2 回答 2

3

不同的分支策略是可能的。但我建议不要将它们链接到任何日历或时间事件（如每日或每周）。

对我来说，以下作品：

  1. 当我启动一项功能/错误修复并看到它需要多次提交时，我为它创建了一个分支
  2. 实现修复bug的功能
  3. 最后将所有新更改从主干（如果有）合并到该分支
  4. 检查所有测试
  5. 将分支重新整合到主干中

如果开发需要很长时间并且主干发生变化，则在开发过程中多次合并主干->分支是有意义的，以免偏离太多。

有时这样的分支可以存活 1-2 小时。有时 1-2 个月（但我不喜欢这样的事情 - 通常这意味着分解不足）。

此外，我从未遇到过需要在分支（不包括主干）之间进行合并，但这又取决于对任务的良好分解。如果一个功能/错误修复完成，它应该进入主干，如果不是，你不应该使用它的中间状态。

于 2013-07-03T07:54:18.703 回答
0

除了maxim1000（+1）的答案之外，我的经验是：

我更喜欢在一个大的单一合并上做更多的小合并，因为你经常需要解决冲突。缺点是在进行大量小型合并时，投入的总时间可能会更大。

当我进行合并时，取决于分支中所做更改的数量和质量。

于 2013-07-03T14:08:17.790 回答