在 SVN 方面需要帮助：Trunk/Branches/Tags 结构

Question

我们目前使用的是没有 Trunk/Branches/Tags 结构的 SVN。到目前为止，我们对它很好，但现在，我们已经达到了需要某种系统的水平，它可以为 3 个不同的服务器处理 3 个不同级别的版本。

目前这是我们一直在做的：

单个存储库中的所有文件，一旦工作完成，数据将提交到我们的开发服务器，经过测试，它被移动到临时服务器，经过另一轮测试，它被移动到实时服务器。

但在上述过程中，我们在开发新功能并同时修复小问题的空间非常小。所以，为了解决这个问题，我想，我们可以使用 Trunk/Branches/Tags 结构，其中最新的开发版本可以存储在 Trunk 中并部署在我们的开发服务器上。

标签可以具有临时服务器的版本（例如 1.0.1、1.0.2 等），分支将具有实时服务器的最新版本（例如 1.0、1.1 等）。

现在，问题是，目前所有的开发都是在本地服务器上完成的，我不确定如何让这个结构在单个服务器上工作，所有开发人员都将在一个根文件夹中工作。

或者我们应该创建 3 个单独的根文件夹（Development、Staging 和 Live）？

欢迎提出任何建议。

Answer 1

我们的进程在部署服务器上包含三个文件夹（尽管我们有时将这三个文件夹分成三个不同的服务器）：/dev、/test 和 /（用于 prod）。

在存储库中，我们致力于主干中的新功能。对主干的更改会自动推送到 /dev 文件夹，因此我们可以实时查看站点的外观。

在预定义的截止日期，我们将主干分支并将其命名为 test，并将测试分支导出到 /test。我们继续在主干中开发新功能，同时修复测试分支中的错误，将每个功能导出到服务器上各自的文件夹并继续测试 /test 文件夹。

一旦我们对测试感到满意，我们就会用一个公开的版本号（比如 1.2）标记它。然后我们将该标签部署到 /（生产文件夹）。然后我们将测试分支中的更改合并到主干中，以便合并我们的错误修复。然后我们开始下一个循环。

Answer 2

您的存储库结构应该独立于您的部署；也就是说，它不应该引用 staging、live 或任何与代码部署后的去向有关的内容。

你描述你的版本号系统的方式，它们都是标签。看看branching and merging chapter of the SVN documentation 的解释。