从SCM不可知的角度来看，标记与修订版非常不同。

两者可以以相同的方式实现，都代表一条“时间线”，但它们的目标不同：

• a tag represent an immutable state where all files are referenced by a unique id. It is a name representing many things but mainly a stable state, ...)
• a revision represent a commit transaction (not all SCM have those, especially the old ones with a file-by-file approach ). All commits do not represent a "stable" state (as in "compile" or "execute" successfully). They are just a new element of the global history.

The problem with SVN is that revision, tag and branches are all implemented the same.
But I would still prefer the option where a tag is used as a "read-only" branch.

在我看来，标签很有用。在项目的生命周期中，有时你会遇到一个bug或更改，你想知道它是否在以前的版本中。将有理由比较一个版本和另一个版本的代码，以衡量代码的性能和实际开发效率。

当然，你有可能把它搞砸，但它总是可以被撤销的。确实没有理由不这样做，而且它在未来可能有用有几个原因。对我来说，这是一件很容易的事。

我同意你也应该使用分支并在那里进行开发，但无论何时你真正发布了一些东西，都要用它做一个标记。

是的，你想使用标签。

可以将标记视为特定修订的标签或名称。根据我的经验，标记项目中的重要里程碑非常有帮助，无论是生产发布还是临时QA发布。您经常会想回到过去，查看特定版本的源代码。

如果你在发布时进行分支，你总是可以弄清楚哪个修订版发布到了生产中，但与只看标签相比，这有点痛苦。如果您不使用发布分支，那么很容易丢失用于创建特定构建的修订版的跟踪。

svn的问题在于它模糊了标记和分支之间的区别。任何人都可以提交一个标记，所以不能保证它是固定的/不可变的。在其他VCS（如PVCS）中，“标签”是不可更改的。您可以采用团队约定来阻止对标记的提交，甚至可以使用提交挂钩来阻止对标签的提交。

我们在创建新的基线时使用标签。我们一周做一次，但有些球队甚至一天做几次。

（对我们来说）重点始终是确保新的基线是稳定的：所以这不仅仅是一个构建，而是一个通过整个测试套件的构建，几个小时的自动化测试，以及潜在的手动探索测试。

然后，在下一次迭代中，基线被用作所有任务的起点：每个新任务都是从基线开始的一个新分支，众所周知，基线是稳定的，因此任务中出现的任何问题都应该很容易在任务本身内部跟踪。

通常，我们只在主分支（或主干或主分支，具体取决于您的SCM风格）上放置标签，这是所有其他分支的集成点。

当我们发布一个官方产品时，我们会创建一个“发布分支”，这样它只会在新开发停留在“主”上时得到修复。然后这些“维护分支”（希望一次只能标记一两个）也可以被标记。

我喜欢把标签看作“只是一个修订版的花哨名称”。我一直这样想他们，而IIRC在反复无常中就是这样。然而，正如你所说，在subversion中，它们确实是trunk/*到标签/花哨名称的（廉价）副本/

老实说，我会将两种策略结合起来以获得最佳结果：发布时标记和分支。你的标签被称为1.0.0，分支1.0-MAINT。错误修复进入分支，错误修复版本再次成为标签（1.0.1可能是一个在某个点上别名为1.0-MAINT的标签。）

然而，不要忘记subversion中的标签和分支实际上是一样的：廉价的副本。它们之间唯一的区别是你/你的团队赋予它们的语义，所以这在很大程度上可以归结为让人们就一个特定的方法达成一致并坚持下去（可能会在服务器上强制执行，例如不允许在标签中提交/发布协调器除外等）

不过，我看到的第二种方法的问题是：如果重新发布1.0，您将如何轻松区分该领域的软件？这意味着你可能有一个1.0和另一个1.0，实际上是指不同的代码库。

项目源代码（和可执行文件）的不可变快照对于进行任何类型的测试都是非常宝贵的，无论是结构化测试还是现场使用。对于结构化测试，您将创建可能在未来数月或数年内引用的数据。Murphy定律说，每当你重新访问这些数据时，你都需要知道它来自什么代码，除非你不厌其烦地引用源代码的特定快照，否则你不可能有把握地说出与测试数据对应的源代码是什么。

我无法告诉你有多少次有人来找我说“这个微控制器代码不工作，你能帮忙吗？”我问他们，“你在用什么版本？”他们说“我不确定”，因为他们没有做好发布管理（至少在设备上贴上标签，最好把版本信息放在EEPROM中，可以实时查询）>；：(

在SVN中，使用标签和跟踪修订之间的技术差异为零。我发现自己最大限度地减少了标签的使用，因为SVN的实现只是一个廉价的副本，并扰乱了你的“结构空间”。

当向一个大型开发团队传达特定的基线时，真正的区别就来了。修订跟踪带来了额外的抽象层，这可能会成为错误的来源。我们都知道，当你与50多名开发人员打交道时，任何错误源都会成为一个混乱和浪费时间的领域。一个冗长的标签可以消除这种混淆，并消除对基线目的的任何疑问。

我会把这两种方法结合起来。无论何时发布，都要标记它。标记永远不会改变，所以“1.0.0”标记的存在表明你不应该试图将其他任何东西发布为1.0.0。

同时，当需要执行1.0.0时，我会将其放到1.0分支上。因此流程是：将trunk分支到1.0，将这个新的1.0标记为1.0.0，然后部署。然后可以在1.0分支上进行错误修复（以避免与任何1.1目标的开发混淆，这些开发现在可能已经在trunk上了），并合并到trunk中。固定1.0的每个版本都标记为1.0分支中的1.0.x。这基本上是我们在使用Perforce时使用的方法，这与Subversion非常相似。（仔细阅读回复，我认为这与Vincent的建议几乎相同）

至于关于标签是多余的评论，因为你有修订号——这基本上是正确的，只是标签还指定了一个范围：即标签覆盖了存储库中的哪些文件。你可以合理地要求某人查看/svn/proj1/tag/1.0.0，他们会立即看到一个连贯的工作空间。如果你让他们看修订版X，他们必须首先看修订版，看看它正在改变（比如）/svn/proj1/trunk/Makefile，从而推断出/svn/proj2/ttrunk/@X是他们应该看的。如果修订版X触及了proj1和proj2中的文件，会发生什么？这当然是邪恶的，但严格来说，你应该说/svn/proj1/trunk/@X。修订号列表存储在哪里？我们如何知道1.0.0是修订版X？IMHO应该可以仅从存储库中确定这一点。

在像Git这样的系统中，标记和分支基本上仍然是一样的（只是对对象数据库的引用），但约定是标记引用不改变，分支引用改变（最好对它们的改变有特定的限制）。Perforce也有“标签”，这是独立于变更列表将一组文件修订分组在一起的方法；这本质上是一个标签，但更令人困惑：历史上，我们使用变更列表编号（相当于子版本修订号）来识别版本，这些编号与它们应该所在的分支的名称相一致。不管怎么说，这两者几乎完全相同，所以这里我猜是TMTOWTDI。