在发布之前和之后我应该如何分支和标记？

Question

我一直在考虑我当前正在使用的部署过程，我想知道是否有一种好的方法来处理将要/已经发布到生产环境的代码的分支/标记。

在某些时候，我想创建一个分支作为发布分支，并对分支进行最后一刻的更改并发布它。然后在发布后我想将其保存为标签。

为了澄清这一点，我正在寻找命名、处理分支和处理标记的约定。我还想知道除了我所说的处理这种情况是否还有其他选择。

• 您是否命名发布分支或每次都使用带有新代码的相同发布分支？
• 一旦发布分支作为标签存在就删除它们吗？
• 你如何命名你的分支/标签？

Answer 1

我建议阅读这个答案

SVN 中的发布管理

基本上有一个名为 RELEASE 的分支，如果您愿意，您可以从那里进行标记。并将最前沿的代码版本保留在主干中

就发布命名而言：这取决于什么最适合您以及谁是看到版本号的人。

考虑使用 MajorRelease.MinorRelease，然后对于技术感兴趣的人来说，您甚至可以指定补丁版本号（例如应用程序自动更新和 Major.minor 保持不变）。

主要的：重大变化 - >新功能/中断兼容性次要：接口兼容（例如性能）补丁：bug修复

Answer 2

即使您不使用 TFS，也可以使用此处的信息作为指导。

分支指导

Answer 3

工作的方式有很多种。我使用的如下：

项目存储库
|
|- 树干 //Where the current in support release is.
|
|- 分支机构 //Where new features/big fixes or refactors are made.
|
|- 标签 //Where all releases are tagged.
     |
     |- 发布 //where all release tags are located
     |- 日常的 //where all daily tags are located.

我们使用的命名如下：

• 对于分支，我们根据其中将要执行的主要任务来命名分支（例如：管理模块重构）。
• 对于标签，我们用版本号命名标签（mayor.minor.micro）。例如：1.0.2) 当它们对应于发布标签时。或者带有日常工作标签的日期（例如：年月日）。

为了遵循这种结构和命名约定，我们有一组工具和脚本来帮助以这种方式工作。此外，构建服务器整晚都会生成每日标签。

Answer 4

我使用 CruiseControl.Net 自动化了构建过程。我们的内部版本与内部版本号相对应，因此 dll 版本为 6.5.4.1234。当我们有主要和次要版本时，6 和 5 总是会手动更新。4 在构建后手动更新（并且 1234 也被重置为 0）。构建过程始终将 1234 更新为 1235。

当我们从主干发布时（版本始终为 6.0.0.x），我们将手动分支并将其称为 Branch_6_0。然后分支将构建为 6.0.1。Trunk 将移至 6.1 或 7.0。

CruiseControl 有两种模式（开发和测试）。测试始终是根据需要创建的，并将创建与构建版本相对应的分支。

Answer 5

在某个时候，我想将分支作为释放分支，并对分支进行任何最后一刻更改并释放

这是让我担心的一点。通常，您需要创建一个分支，在其上进行所有开发，然后将该分支与主干重新集成。从此时开始在树干上创建标签。如果您想进行更多更改，请创建新分支、编辑、重新集成并重新发布。

不要尝试对发布分支进行更改，因为您可能会丢失它们，或者在将它们合并回主干时遇到麻烦。

发布分支的另一种方法是对主干进行所有开发更改，当您准备好时，创建一个发布/标签分支。对于小型开发商店来说，这通常是最简单的方法。（当您对其他人也在进行更改的产品进行重大更改时，另一种方法效果很好）。