1

这是我试图找出解决我的问题的最佳方法的一个月,这是最好的。我想知道你是否同意。

我们正在开发一组互连的 Web 应用程序。我们将每个应用程序视为独立于其他应用程序的单一解决方案。每个应用程序都由不同的项目组成,但这并不重要。

我们用于在主干上开发新功能。每当我们实时发布内容时,我们都会用版本名称标记主干版本。例如,假设第一个主干版本标记为 1.0.0。当我们开发进一步的实现(即我们正在开发 1.1.0)时,生产版本会出现一系列错误。我们正在考虑做的是检查标签 1.0.0 并更正版本 1.0.1 的错误。

现在我们想要完成的是标记每个修订版本。换句话说,我们希望能够拥有 1.0.0、1.0.1、1.0.2 的完美工作副本......

现在这是我的解决方案,我想知道您是否同意。

  1. 我将我的标记版本 1.0.0 签出到本地 /tags 文件夹
  2. 我将此版本分支到 /branches/1.0.1 存储库文件夹
  3. 我将我的新分支签出到本地 /branches 文件夹
  4. 我更正了分支 1.0.1 上的错误
  5. 当 x 提交后一切正常时,我将这个新版本标记到 /tags/1.0.1

对于每个新错误/新版本,依此类推。我试过了,如果我检查 /tags 文件夹,我可以看到所有版本,完美的工作。

现在,当我准备好 1.1.0 时,我应该使用“合并一系列修订”选项合并主干上的最后一个标签(或分支,如果一切正确,它们最后应该是相同的)。合并所有内容后,我应该有一个完整的 1.1.0 版本,并且过去已更正了修订。编译、测试然后发布,显然,将其标记到服务器上的 /tags/1.1.0 文件夹。

你怎么看?谢谢,马可

4

4 回答 4

2

通常所有的开发都是在主干上完成的,主干是你发布的基础。您可以使用分支来稳定代码以准备发布,修补发布或实现由于多种原因无法在主干上开发的功能。

当使用分支进行稳定化或修补发布时,错误的修复或应该进入稳定化分支的更改都在主干上开发,并有选择地合并到分支。

使用功能分支时,您提交到分支,然后合并回主干(可能从那里合并到稳定/补丁分支。

简短的故事,我想念您开发周期中的主干,我想知道您如何确保所有更改最终都在主干中,因为这是您的下一个主要功能版本将/应该从那里开始。

于 2010-09-28T18:39:48.427 回答
1

这看起来是一个非常好的过程,除了你在生产分支上的错误修复很可能也需要反映在主干中。因此,最后不需要将所有内容合并到主干中,因为您已经完成了。

否则,您似乎确实在适当地使用分支和标签,所以对此表示赞赏。我见过太多无法在源代码控制中识别当前(或其他)生产版本的项目(如果您需要修复某些东西或回滚,这是必不可少的)。在我看来,这没有任何借口。

于 2010-09-28T18:26:58.780 回答
1

你所描述的对我来说听起来像是标记和分支的正常程序。这就是我使用颠覆的方式,而且效果很好。

于 2010-09-28T18:29:01.067 回答
0

听起来不错。

根据发布的修复数量,我不会为每个次要版本创建分支。创建这些,与人们交流要结帐/在哪里签到,合并等。冲洗并重复。

每个主要版本都有一个分支并将其用作“维护”分支,这对我们来说效果很好。

如果您感兴趣,这里是对该过程的描述: svn deployment strategy for multiple groups of developers (not co-located) working on different components of the same project

仅当您必须执行不符合当前策略的操作时,才为分支定义策略并创建新分支。有助于限制分支。

于 2010-09-30T16:10:57.023 回答