我一直在考虑我正在使用的部署过程，而且我想知道是否有一种好的方法来处理分支/标记将要/已经发布到生产中的代码。我应该如何在发布之前和之后进行分支和标记？
在某些时候，我想创建一个分支作为发布分支，并对分支进行任何最后一分钟的更改并发布它。然后释放后，我想将它保存为标签。
为了澄清，我正在寻找关于命名，处理分支和处理标记的约定。我也在想，除了我在谈论如何处理这种情况之外，是否还有其他选择。
我建议阅读这个答案
基本上有一个分支叫版本中，您可以从那里，如果你想标记。并保留行李箱中的流血码版本
就发布命名而言：它取决于最适合您的是什么，以及谁是看到版本号的人。
考虑使用MajorRelease.MinorRelease，然后也许某个地方的技术上感兴趣，你甚至可能指定一个补丁版本号（例如，应用程序autoupdates和major.minor保持不变）。
专业：大的变化 - >新的功能/场所兼容性 次要：接口兼容（例如性能） 修补缺陷修复
即使您不使用TFS，也可以将此处的信息用作指导。
我自动使用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有两种模式（开发和测试）。测试总是按需创建，并会创建与构建版本相对应的分支。
在某些时候，我想打一个分支 为发布分支，并作出 最后一分钟更改分支和 释放它
这是我担心的一点。通常情况下，您需要创建一个分支，完成您的所有开发，然后将该分支重新集成到主干中。从干线上的这一点创建您的标签。如果您想进行更多更改，请创建一个新分支，进行编辑，重新整合并重新发布。
不要尝试对发布分支进行更改，因为您可能会丢失它们，或者有麻烦的时间将它们合并回主干。
释放分支的另一种方法是将所有开发更改为主干，并且当您准备好时，创建一个发布/标签分支。对于小型开发商店来说，这通常是最简单的方法。 （当您对其他人正在进行更改的产品进行重大更改时，另一种方法运行良好）。
工作方式很多。我使用的一个是：
project_repository
|
|- trunk //Where the current in support release is.
|
|- branches //Where new features/big fixes or refactors are made.
|
|- tags //Where all releases are tagged.
|
|- releases //where all release tags are located
|- daily //where all daily tags are located.
我们使用的命名如下：
对于遵循这种结构和命名约定，我们有一组工具和脚本来帮助以这种方式工作。每天晚上，构建服务器也会生成每日标签。