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 回答