【问题标题】:How often do you merge? [closed]你多久合并一次? [关闭]
【发布时间】:2013-07-03 06:59:12
【问题描述】:

我是一名开发人员,正在学习如何使用源代码控制软件。我已经阅读了Subversion documentation。我了解合并的概念,但我的问题是:您多久合并一次?

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

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

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

过去(当我没有使用源代码管理时)我已经发布了。我认为最好设置一个我(和其他开发人员)可以努力的发布日期?

我今天准备了很多关于合并和分支的帖子,例如这个:Good branching and merging tutorials for TortoiseSVN?。我还没有找到具体问题的答案。

【问题讨论】:

  • 你尽可能频繁地合并,在你的情况下,每天结束听起来是个不错的选择。经常合并的原因是如果存在依赖/代码冲突,它们更容易维护。

标签: svn version-control merge branch


【解决方案1】:

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

对我来说,以下作品:

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

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

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

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

【讨论】:

【解决方案2】:

除了maxim1000的答案(+1),我的经验是:

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

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

【讨论】:

    猜你喜欢
    • 2021-12-05
    • 1970-01-01
    • 2021-07-14
    • 2011-08-01
    • 2011-01-04
    • 1970-01-01
    • 2010-09-05
    • 2014-07-28
    • 2010-09-26
    相关资源
    最近更新 更多