首选版本控制方法

我相信你在网上搜索这个话题的答案时已经注意到,这是最好的答案之一,答案是“视情况而定”。正如大多数回答所指出的,这是在提交/合并新代码的容易程度与管理可轻松回滚以支持或调试的广泛版本历史之间的折衷。

根据你的问题,我想我们属于一组开发人员,他们总是试图保持一个稳定的主干,我们在将新代码合并回主干之前对其进行分支和测试。我们还努力保持每个版本发布的“快照”,以便在必要时,我们可以轻松地签出早期版本并重新构建它,而无需合并任何用于未来版本的新功能(这也是跟踪bug的一个很好的机制,因为您可以使用早期版本的代码来帮助确定特定bug是何时首次引入到您的代码中的。但是,需要注意的一点是,如果您的应用程序引用了与版本代码分开维护的公共代码,则您需要跟踪该代码太好了。

• 大旅行箱

  • v1.0.1.x版本

  • v1.0.2.x版本

    • <
    • v1.0.2.x错误修复程序B

  • v1.2.1.x开发 <

    • v1.2.1.x新功能A <--(这些将合并回开发分支)

当我刚开始在该公司工作时,我们的版本结构并没有那么复杂,根据我的经验,我想说,如果您有任何需要跟踪早期版本,那么将这样的内容整合起来是值得的(正如我前面所说,只要它符合您的个人需求,它就不必看起来完全像这样),将其记录在案,以便所有出资人都可以维护它(另一种选择是,创造者最终“看护”回购协议,这很快就会成为难以置信的时间浪费),并鼓励您的所有开发人员遵循它。开始时可能会觉得需要付出很多努力,但当您第一次需要利用它时,您会感激它。

不同之处可能与给定版本控制系统中合并的痛苦程度有关。

有了git,分支和合并实际上是不费吹灰之力的,所以保持我的主界面整洁并在分支中完成所有工作对我来说是一个常见的工作流。svn中的分支和合并,特别是在以前的版本中,并不是很便宜和容易,所以当我使用svn时,我倾向于直接在主干上工作。

对我来说,有一棵破树意味着少了一个知道我在做什么的方法 正在做什么。

在分支和稳定版本中都会进行重大更改,并在任何给定的时间点进行尽可能小的更改,以保持良好的进度。

任何稳定的释放都应从行李箱中取出。任何进一步的工作或修改都应该进入工作分支内部,并在准备发布时与主干合并。

如果有多个独立的开发,每个组应该有一个分支,它们应该定期与trunc同步,并在准备就绪时将其合并回主干。

我一直使用主干作为代码的头部。通常,新的开发代码会出现在那里。

我们为发布分支,我们可能为一个“大型”破坏稳定的实验分支。

如果大实验成功了,它就会被合并回主系统。

我们在版本分支和主版本中使用内部版本号标记。这样我们就可以返回到特定的版本,并在必要时进行构建。

尝试并保持简单开始,我总是尝试有一个已知的工作版本,可以复制用于测试和部署等。根据您的存储库,您可以使用修订号(SVN),或者只标记已知的工作版本,因为它们是必需的。

如果你发现有多个人接触同一个文件,那么你就需要考虑一个分支策略,除了这样一个小的开发团队,它将是不必要的开销……(IMO)

一个方面是这些变化将处于不稳定状态多久。

当我所做的更改可能影响其他人或夜间构建时,我会在分支上进行工作,并在稳定时进行合并。

我使用标签的一种变体来实现可重复的构建——因此,如果我需要返回到一个稳定的版本进行bug修复,我可以使用标签信息来实现这一点。能够按需获得稳定的版本至关重要。

一个关键区别是文件的平均大小。大文件(1000行以上)往往有许多独立的更改,这些更改可以自动合并。因此,其他人正在主动更改您将要开始处理的文件这一事实可能是无趣的,因此,如果系统难以发现这一点,也没关系。

因此,你倾向于采用一种风险投资策略,这种策略有很多分支,并且容易合并。新功能是在新的分支中编写的。

如果您使用的是像Java这样的语言,使用的是OO设计中典型的较小、高度内聚的文件,那么这种意外冲突就很少发生。即使作为一个人工示例,也很难提出两组可以对类(以及相应的JUnit测试用例)进行的更改,这些更改可以合理地单独进行,然后通过文本合并工具自动重新组合在一起。

所以你最好选择一个VC策略,它有一个可识别的、可用的、稳定的主干和最少的分支。

在第一种方法中,新功能在新分支中编写,完成后合并。在第二种情况下,它将写入新文件,并在完成时启用。