如何在源代码管理存储库中维护源代码版本和项目树结构

Question

对于使用(VSS) 2005的4-5个开发人员来说，维护源代码版本的最佳实践是什么？

我们的要求是维护和识别目前正在生产的版本。这样，在任何时候，我们都可以知道在部署过程中推动了什么代码。

到目前为止，这是我的想法。

-trunk -主要解决方案和项目

-Dev分支-为开发和增强创建的分支-Dev (一些增强) -Release -发布分支-Release 2.1.0 -Release 2.1.1 -Release 3.0

上面以破折号(-)开头的所有内容都是存储库中的一个文件夹。

我在想，每次我们需要对我们的项目进行增强时，我们都会从整个项目的主主干中创建一个开发分支。这将是开发人员工作的地方。一旦开发完成，UAT完成，我们就继续进行部署。

在部署了项目(在本例中是web应用程序)并确认它是稳定的之后，我们在上面的Dev分支中创建了一个版本(version #)分支。假设这是3.0版本，我们现在知道在2010年7月部署时，我们将代码推到Release3.0文件夹中。

然后我们将发布的3.0代码与主干合并(在VSS2005中这很容易)。这样，主干始终是最新部署的代码，下一个增强将从主干分支。

HotFix

有些事情我还没有弄清楚，当存在一个正在工作的Dev分支，并且需要立即部署一个热点修复时，会发生什么。

也许，我们在最新的发布文件夹中创建了一个独立的分支，称为Hot-Fix3.0。让开发人员进行修复，在部署热修复后将其与Release3.0代码合并，然后再与主干合并。

清理

发布后，实际上不需要开发分支。这些应该删除吗？

因为我们是分支，我看到在VSS中删除一个分支不会释放数据库中的空间，除非原始的被删除。

我们应该如何删除，还是应该删除dev分支？

这些是我的想法，您如何管理您的版本，以及您对我的需求的建议。

我们将来可能会转向TFS，所以我现在在VSS中实现的任何东西都应该在将来考虑这一举措。

Answer 1

committed)

• merge
• 主干->只应包含稳定的代码
• 标记->，向主干代码添加标记以识别版本(例如，2.1.0、2.1.1、3.0等版本)
• 分支->为每一个问题创建一个分支，
• 更新->更新分支经常使代码尽可能接近主干(因为在解决方案稳定的情况下，
• ->将分支合并到主干的其他修复(包括问题号，以便代码更改与问题号相关)

< code >F 211

最重要的是：

• 使用一个源代码管理系统，它支持您做所有这些-> VSS将不做的事情;)

在这篇有趣的文章中也可以看到：http://betterexplained.com/articles/a-visual-guide-to-version-control/